There's nothing "practical" about HTTP/2.0. I've read the spec, since I was interested in it, and it confused the hell out of me. Then I learned that even people who implement networking specs for a living, and have tons of experience at it, are stuck trying to figure out how to implement the current spec.
So if you're going to push for shitty-but-practical, at least make sure you have the practical bit.
For instance moving cookies to the server side would just require a simple key-value store lookup.
Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead?
Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?
My proposals is to do that, and have the top bit in the session-id mean "Persistent" or "Anonymous", so that client undisputably controls if anything will be stored about the session.
A Pesistent session-ID would be the same next time you visit the site, an Anonymous would be random, and thus not retrive any state on the server side, even if they saved it last time.
This would put the privacy decision in the hands of the client, provided we also eliminate crap like almost-per-user-unique user-agent headers.
Or are you pushing for browsers to turn off cookies by default?
On the protocol level, there is a huge knowledge and API momentum that makes any protocol that fundamentally differs from HTTP an uphill battle for adoption. Whatever changes are made to HTTP, if it is too different from the application POV, it will linger behind.
Same thing about tunneling. It may not be elegant, but it's the way to fight the system. You won't change IT behaviour with a protocol change. One possible way to work would be to make new version oF HTTP have a working mode that reduces overhead to a minimum for any tunneling operation.
(The same argument hold to SCTP vs TCP.)