OK, I was a bit confused when I first read your report: XHR objects actually ARE created, but the request is not issued immediately. You can create as many XHR objects as you want, but only 6 (in the example of Chrome) will be issued concurrently (I suppose it's 6 per domain). Even worse, it may very well be a cross-tab limitation (making it impossible to have more than 6 concurrent requests per domain for the whole collection of tabs actually opened in Chrome).
That being said, it may be possible to inititate the timeout only when the readyState changes to a "requesting" state but is it desirable? When you set the timeout in ajax, you do express you want the request to be complete in, say, 8 seconds top. That the timeout is due to the server hanging or the request not being issued by the client yet is somehow irrelevant. The timeout set in the ajax options is an applicative timeout (it will incidently also work for script tag injection, knowing that this particular technique is even more limited in its number of concurrent request per domain). It will be impossible to ensure any kind of consistency here between different transports.
Furthermore, when I see that many concurrent requests to the same domain at the same time, I'm starting to wonder how the application is architected. You could easily group/multiplex requests client-side and ungroup/demultiplex requests server-side (it may even be possible to create a transport that does just that).
I know it sucks when you're hitting limitations of the browser, but jQuery can only do so much magic before becoming an inconsistent piece of script.