Original text:
act as a client on some connections and a server on others. HTTP is defined as a stateless protocol, meaning that each request <del> message can be understood in isolation.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.  Hence, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </del>  3.4.

Reviewer comments:
though I do wonder if HPACK/QPACK needs to be explained as well, since the order in which messages are processed does impact their compression, but not their interpretation.
I would probably say that as the semantics are still stateless, this document probably doesn't need to say anything about that. But that's a weak preference only.
The change looks good to me. That said, it might indeed be good to mention the impact of header compression.
I clarified that this was about semantics. I'm hesitant to talk about header compression, as that's likely to just confuse the matter.
I thought that was already clear. We might need to mention HPACK/QPACK anyway because they are only stateful with regard to the in-transit encoding between peers, and thus deliver stateless messages at the HTTP layer. Or something.
Clarify if the request needs to be the 1st request after a connection is opened.
Is there a reason why you ask? Are there problems when it's not the 1st request?
I'm not aware of any such problem, and for example in haproxy we do support upgrades anywhere.
Just a question I had .. which I feel the spec may want to call it out, either 1st request only or no such restriction.
Nothing in HTTP depends on where a request is placed upon a connection, because it's a stateless protocol. see last paragraph (this is likely to move to soon, which is more appropriate. Should we spell this out more clearly there?
Probably, it never hurts to remind it.
I see the case for proxies to reuse and upgrade an existing connection to the server. Mentioning this will encourage correct server implementations.

Revised text:
act as a client on some connections and a server on others. HTTP is defined as a stateless protocol, meaning that each request  <ins> message's semantics can be understood in isolation, and that the relationship between connections and messages on them has no impact on the interpretation of those messages.  For example, a CONNECT request (CONNECT) or a request with the Upgrade header field (field.upgrade) can occur at any time, not just in the first message on a connection.  Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers. As a result, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent.  Some non-standard HTTP extensions (e.g., RFC4559) have been known to violate this requirement, resulting in security and interoperability problems. </ins> 3.4.