Code change:
Regarding the case of multi-valued header, we have this: I'm not seeing anything there which forbids the use of "Content-length: 5,10" anymore. I'd rather emphasize the need for extremely strict parsing of Content-length and keep the duplicate case as the only acceptable exception to this rule, approximately like this: "The Content-Length header field plays a crucial role in message delimitation in HTTP/1.1, and a different error handling between agents was shown to have important consequences in terms of security. As such, it is extremely important that agents do not accept Content-Length header field values that do not strictly comply with the ABNF, that they take care of rejecting values that they are not able to accurately represent internally, and that multiple occurrences of the header field are always checked for, and rejected as invalid. As an exception, if the header field is received multiple times with the same value, or is received as a comma-separated list of identical values, the recipient MAY replace all of them with a single valid Content-Length field containing that decimal value instead of rejecting the message."
Messaging 6.3 says: I think that covers it for HTTP/1.1 (if Transfer-Encoding and Content-Length are both present, that's encouraged to be handled like an error). HTTP/2 says: HTTP/3 says: ... so we could say something in semantics about invalid content-length fields when it's not being used for delimitation, if we wanted to.
Hmmm interesting. I haven't read enough of both parts yet but it's not that bad because I'm in the same situation as someone seeking a solution. I think in the semantics part, there should be an explicit reference to the messaging, for example, "Certain versions of HTTP use Content-Length for message delimitation and may impose stricter rules". This could be sufficient to make the reader check the respective messaging parts. What about the point about being careful about internal representation (i.e. no overflow nor loss of resolution) ? I know I placed it in the middle of the text because it flowed naturally, but this remains a valid item as well.
As a general rule, I think we should not add text to semantics that says some other document has a requirement unless that specifically enlightens the reader regarding the meaning of that protocol element. This is important because the Semantics spec is already "too long" for easy review. If the requirement matters, it will be read by readers of that other document.

Related discussion:
text: programs perform for a particular connection.  The same program might act as a client on some connections and a server on others. <ins> HTTP is defined as a stateless protocol, meaning that each request 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. </ins> 3.4. HTTP is a stateless request/response protocol for exchanging