Code change:
The user agent includes stored cookies in the Cookie HTTP request header field. <del> When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field. </del> A user agent MAY omit the Cookie header field in its entirety.  For example, the user agent might wish to block sending cookies during "third-party" requests from setting cookies (see third-party- cookies). If the user agent does attach a Cookie header field to an HTTP <del> request, the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </del> <ins> request, the user agent MUST generate a single cookie-string and the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </ins> 5.7.2.

Related discussion:
text: This seems to stem from 6265bis's tendency to re-implement other specs requirements, but in a somewhat inferior way. The cookie spec probably shouldn't care how the HTTP request is specifically formed so long as the invariant of a single cookie-string from UA -> Server is maintained by the time the server's cookie processing code receives it. URL would probably help here. In the meantime, I'd prefer if we didn't special case actions such as 9113's cookie header field splitting, so maybe some rephrasing could avoid the issue? Here's a rough draft of what I mean. My intention here is to make it clear that the UA (more specifically the cookie code) should create a single cookie-string to attach as the header's value. This would lead to a single header in the default case, but should still allow for header splitting.
9113 and 9114 have to special-case Cookies for one simple reason: they're a semicolon-delimited list rather than a comma-delimited list. 9110 ; the text in question applies the same logic to Cookies despite the different delimiter and points out that for compression reasons it's particularly useful to split Cookie fields. (It might have been worth noting that other list fields might see similar gains from being split and recombined across the compression boundary, too.) I think NAME proposed text on generation is fine -- there should always be exactly one Cookie header generated from UA->server, though a lower layer might mux it before compression. After decompression, demuxing is mandatory when being passed into a context that doesn't know to expect being split. However, there's that exception in both RFCs: "URL being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application." This text clearly supposes that anything version-specific which comes after RFC 7540 will know that Cookies may have been split; perhaps this document should prescribe tolerance of receiving that on the server side. It's then an implementation concern whether that tolerance takes the form of recombining them before processing.
Which document specifically?