Original text:
prevent parsing errors due to integer conversion overflows (attack.protocol.element.length). <del> If a message is received that has a Content-Length header field value consisting of the same decimal value as a comma-separated list (abnf.extension) -- for example, "Content-Length: 42, 42" -- </del>  indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, then the recipient MUST either reject the message as invalid or replace the

Reviewer comments:
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.

Revised text:
prevent parsing errors due to integer conversion overflows (attack.protocol.element.length).  <ins> Because Content-Length is used for message delimitation in HTTP/1.1, its field value can impact how the message is parsed by downstream recipients even when the immediate connection is not using HTTP/1.1. If the message is forwarded by a downstream intermediary, a Content- Length field value that is inconsistent with the received message framing might cause a security failure due to request smuggling or response splitting. As a result, a sender MUST NOT forward a message with a Content- Length header field value that is known to be incorrect. Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, with one exception: If a message is received that has a Content-Length header field value consisting of the same decimal value as a comma-separated list (abnf.extension) -- for example, "Content-Length: 42, 42" -- </ins> indicating that duplicate Content-Length header fields have been generated or combined by an upstream message processor, then the recipient MUST either reject the message as invalid or replace the