The issue also occurs using Chrome Canary

Some more information now that I have managed to fix the issue properly on our system. I noticed that the common factor before all of the failing/pending requests was that the previous response was a 204. Using Fiddler suggested that occasionally the 204 responses were including spurious content, I'm guessing that this content was getting picked up by the NEXT response and causing the duplicate header read (and dropping down to HTTP 0.9) problem. Luckily we have a small proxy between our client and the application server and I was able to modify it to ensure that 204 responses are now guaranteed to have no content. This stopped the issue with Chrome.
Things I am still unsure of:
1) Why the spurious content existed and in particular why we only see it when the server is running Linux although I accept this isn't anything to do with Chrome
2) Why we only see the problem with Chrome for Windows and not the other OSes? I'm going to take a guess that maybe the low level network handling is different across OSes so maybe this is why.

Thanks for the followup.  It would be nice to know the answer to 2) but since the root cause of the problems seems not with Chrome, I'm going to go ahead and mark this issue as archived.  

The network stack's handling of responses is the same across all OSes.  It could be differences in platform-specific TCP socket behavior, though.  If we see the extra junk on a socket before we try and reuse the socket, we'll close the connection and create a new one.  If we see it after we try and reuse the socket, though, we're in trouble.

There was also some weirdness discovered in Chrome's logic here - if we read all available extra data from while reading the HTTP headers, we'd still reuse the socket, instead of throwing it out after processing the response.  i.e., if we got:

HTTP/1.1 200
Content-Length: 0

Random junk that's not part of the HTTP response.

We'd reuse the socket if we read that entire response at once, despite knowing we had extra data.  And then if we received more extra cruft after that, we'd treat it as an HTTP/0.9 response.  If we had unread cruft on the socket when we try and reuse it, though, we'd correctly throw away the socket.

I recently landed code to always throw away the socket in that case, but it's not on stable yet.

Regardless, this is just a mitigation for server bugs, and to make our behavior closer to other browsers.  The servers should (obviously) be fixed.