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: Technologies such as HTTP/2 will split the header into multiple fields. This PR modifies the spec to no longer expressly forbid this and instructs servers to be aware and capable of handling multiple incoming headers.
In the original 6265 as well as in the latest 6265bis draft, this paragraph exists: This is directly contradicted by RFC 7540 and then : I personally suspect that trying to split the header up into multiples is a recipe for disaster and interop problems even if done only over HTTP/2, but maybe I'm just a pessimist. Would it be sensible to maybe address this contradiction (better) in the bis document?
HTTP/3, repeats the HTTP/2 statement as well: Both these HTTP RFCs also clarify that: But still, that is for the receiving end and does not really restrict the sender when using HTTP/2 or HTTP/3.
I agree that the inconsistency is bad. That said, why do you believe that using multiple field instances can cause an interop problem?
I'm fairly sure Chromium does this, so if there were interop problems, we'd probably have noticed by now. :-) The phrasing is a little odd and probably could be improved. One resolution is to say this is an HPACK-specific encoding thing and not actually sending multiple fields. The full text from 9113 says: I.e. this field splitting starts and ends its life in HTTP/2.
A concern: Some servers have a maximum request header field size limit of around 8K. curl makes sure to never send a header longer than that as it risks getting a 400 back and basically blocking that particular request without it being very obvious to the user. This is a limit RFC6265(bis) does not mention but probably should because it is one of the more important ones. By splitting up the header into multiple ones, the total size of the sent cookies should probably still remain smaller than 8K since there is a risk that there is a h2/3=>h1 conversion done that will pass those cookies on in a single header and thus be affected by this limit. It would if HTTP/3 didn't have the same wording so it also applies there.
Because one RFC says we MUST NOT send them and another says we MAY.