Section 4.6.3. - "the timeout attribute" non-normatively explains 
"Can be set to a time in milliseconds. When set to a non-zero value will cause fetching to terminate after the given time has passed."

Later sections
"4.6.7 Infrastructure for the send() method" normatively specify:

"If timeout is not 0 and since the request started the amount of milliseconds specified by timeout has passed"

This implicitly does not rule out the situation where a timeout is set for an XHR first, then send() is called on it, and then the timeout attribute is updated to a new value, either shorter, or longer. A shorter value leading to an earlier timeout, a longer value giving the request more time to complete. Let's call this situation a "late timeout override".

I would like to see clarification on whether the spec authors expect the UA to support such late overrides or whether a late timeout attribute override should have no effect.

My experience from trying to implement this on Blink shows that it would lead to layering violations in the loading code. After the request is sent out, Blink currently has no means of updating loader parameters to update the timeout and hence updating the timeout timer to for example fire and abort the request earlier.

While it's feasible to refactor Blink to allow this, I would like to raise the question whether the late timeout override behavior is desirable and intended. Similar semantics are achieved with aborting the request, reconfiguring a new timeout value, sending it out again.