@theZerg Some nodes may not receive thinblocks as there has to be some entry way into the thinblock node network. So I"m not sure you can favor thinblock nodes without the risk of splitting the network, or at least we would have to make very sure that doesn't happen.
Can I ask what how many thinblock nodes your connected to? There is a small problem such that if a node connects to two nodes with the same IP but different ports but doesn't have a third connect-thinblock then it would appear as a crossconnected node and download a regular block. This would be exceedingly rare and I believe that's what you may have done since we don't have that many nodes up right now. I see you have a connection in to both my nodes which are on different ports but same ip?
You said:
"It looks like the code responds via a thin block to clients that request thin blocks. So we essentially have an efficiency race condition here where if an INV is received from a thin-block node then then our node requests a thin block, otherwise it requests a fat block"
Actually there is no efficiency race...if you use "connect-thinblock" it will *only* download from a thinblock node unless there is some kind of cross-connect going on. If it can't immediately download a thinblock it will spin around until it gets an INV from a thinblock node.
If you haven't already done so you could also add
104.197.99.28 as a connect-thinblock node. That should clear up the issue of the false cross connect.