Is it possible to write a server which supports both versions?
This is "draft" for a reason, and note this is not a final protocol, it's another draft. That's for a reason too. Don't expect your -76 server to last forever with no changes either.
It's possible to support both, and that's what I'll personally be doing with my own web server.
The changes I've seen don't add any obvious extra security as such, just make it a little more difficult.
edit: Please give clear references when you say "Fundamentally insecure protocol". That's pretty much totally unfounded. What type of security are you talking about?
Directly from the article: "introduces nonce-based challenge-response to protect from cross protocol attacks." In my experience, when people identify a possible security attack it's usually correct. (The solution can be another matter, but I'm not looking at this enough to have even an uninformed position.) The problem the sort of people working out a protocol like this have is missing ones that are possible, not pointing out ones that don't exist.
If you're comfortable with unnecessarily insecure lower layers, more power to you. Don't expect plaudits from me. Or expect me to be taking security advice from you after casually disregarding things like "security in depth".
All the new version does, is send over some obscure challenge data (generate a random number, then insert random characters into it????). Then it expects a response from the server with the value md5(challenge).
That does indeed get rid of a class of cross protocol attacks, but it's a ridiculous edge case as far as I can see.
Previously you may have been able to find some server (non HTTP), that you could connect to, somehow get it to respond with the correct HTTP headers in exactly the right order, and continue. Then exploit it - send spam email, etc etc
That's pretty unlikely.
Now, you'd have to get that server to respond with the md5 response, which is fairly impossible.
BUT. The security here is in Browser->"Some non HTTP server being tricked" - eg something I don't care about too much. Make your "non HTTP server" more secure. For example see the recent exploit against freenode earlier this year, where they allowed connections from an automated HTTP POST in the Firefox browser - the ircd just ignored any HTTP stuff and happily connected users to spam away. The fix wasn't to update the HTTP protocol or firefox, it was to patch the ircd so it actually checks what protocol the client is speaking (And also PING/PONG checks etc)
So, your premise that the original spec is somehow insecure to use within a browser->webserver context, is completely incorrect.
Right now I've already made http://beaconpush.com support two different versions of Web Sockets implemented by different versions of Google Chrome. (There were differences in the handshake origin URL).
Don't get me wrong though, I'm not complaining. I knew what could happen. It's just that the hype surrounding Web Sockets rarely mention these more cumbersome details of the protocol still being a draft.