That is terrifyingly evil. And I mean that in the best possible way.

As someone who doesn't have a very subtle understanding in English, I can't figure out if this is an endorsement, or very much not one? (serious question! I'd rather fly by your crypto-intuitions than my own...)

It's incredibly cool. Not something I'd necessarily want to actually use in production, though.

The concept that the protocol multiplexer uses is pretty sound and simple. I have and would continue to deploy in production, but as usual you have to know what is going on and what the implications are. You do pay a known penalty in complexity and startup time but you gain a world of obscurity. It's like every other tool; it has it's uses, but it's not suitable for all problems.

The fact that an implementation is possible in a few pages of C goes a long way, especially when the install base for that tool is small and you need to understand the details. If nothing else, the concept stands on it's own and might offer ideas in solving other problems.

In the ssh protocol, the server sends a banner first. For HTTPS, the client sends certificate data first. How is it possible to run these 2 services on the same port without changing the client?

The link he gave is a custom multiplexing daemon that handles those cases. A timeout value is used to connect to the SSH daemon if the server hasn't received anything from the client.

I've done the same thing to set up a "SVN-or-git repository" on a machine on which I only had my own shell account. Fortunately, that never made it to production.