Whenever the market finally settles down and I have the time to actually work on COMB, I've got a few things in mind.

 - More accessible information regarding the mechanics of comb. I've tried to simplify it already, but it can be made easier for people to understand, especially if there are proper diagrams made.

 - LStack stack modifications. Right now if you make a multi-out transaction with 5 destinations, you're looking at including 5 LStacks in the data you give to the recipients; they make mono-directional main pipe that has lateral exit valves, each valve spitting out the amount required for that destination address. Instead, I think it makes more sense to switch over to a merkle tree design; LStack1 is made up of LStack2 and LStack3, NOT Destination1 and LStack2. If I'm not mistaken this should significantly cut down on wallet metadata in large transactions; the total metadata generated with the current system can be calculated with n = (x/2+0.5)*x, where x = destination count. The merkle tree variation generates about n = l*x, where l = the merkle tree layer count. If you shoot off a transaction with 4 total destinations, you're looking at a metadata value of 10 with the current method, but a metadata count of 8 with the merkle tree variant. Unless I'm missing something, this makes sense to implement. I realize there's a "fold the stack" option in the client currently, however I haven't looked into what it actually does mechanically, and it says that it should only be used for super large transactions, so I'm assuming it wouldn't help in situations like the previously described.

 - Light wallets. The three ways I see to work this are a) a trusted 3rd party comb node to host the commits files, b) a trusted 3rd party comb node to feed to commits to build your own commits file, or c) multiple 3rd party BTC nodes that your downloader connects to. I'm guessing C is probably going to be the way to go in the long run, but that involves a larger community I would assume.

 - Security. A guy on the TG made some good points about the vulnerabilities that the current method of command has, It makes sense to build a proper, secure RPC system going forwards; it also may make building a native GUI easier. I know that guy was working on a QT GUI, but I haven't heard anything in a while.

I can't really speak to the more technical comp-sci possibilities of optimization, I haven't done enough reading to really comment yet.