Code change:
End of section 3.5 () says: First of all this paragraph seems to be in the wrong section because it's more generally about the capsule protocol and not the datagram capsule. However, it's also confusing. I believe if you negotiate http datagram with the H3DATAGRAM SETTINGS parameter, you always need to also support capsules even if QUIC datagrams are supported, as the other end (e.g. an intermediary) could send you anyway a capsule. Or is this text meant to say that new extensions that use the http datagram but have a new settings parameter for negotiation may not need to support the capsule protocol? I think it would be good to clarify both: what this sentence/paragraph means and what is required if you negotiate http datagrams using the H3DATAGRAM SETTINGS parameter.
I want to extended on this issue a bit more. A lot about the implementation requirement on different nodes are implied rather than being explicit. "Secondly, I will note that the above text combined with what is written in Section 3.4: Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT." If an intermediary is doing this unaware re-encoding and the HTTP extension is an extended connect version it can result in interoperability failure when a Datagram capsule arrives at the endpoint that only supports HTTP/3 Datagrams over QUIC Datagram.
If we build off the notion that H3DATAGRAM setting communicates a willingness to receive the HTTP/3 datagrams (in QUIC datagrams), they still require some request to bootstrap the association, otherwise those datagrams would be ignored. In theory, I could define a new method called "ALWAYSUNRELIABLE" that can be used to bootstrap a request stream and it be defined to never use a capsule protocol. If a server sends me data on that stream, I could ignore it or throw an error. I don't need a new setting to caveat this behaviour.
NAME but then you can't have "blind" re-encoding of HTTP/3 Datagram to Datagram capsules, I think it is that simple. So we need to choose if HTTP Intermediaries can re-encode when they don't know the Upgrade Token or if they can't and must be aware and thus enable cases where some have different behaviors. See
There is no such thing as "blind re-encoding". Intermediaries can only perform re-encoding when they know that the capsule protocol is in use. Intermediaries can learn that by knowing the HTTP Upgrade Token, or by watching for the Capsule-Protocol header. But I think we can make that clearer by spelling out in the "DATAGRAM Capsule" section that intermediaries MUST NOT re-encode to capsules unless they know for sure that the capsule protocol is in use.
PR did not address the editorial point that this paragraph is in the wrong section.
I don't agree with that editorial point. The paragraph is about the interaction between HTTP datagrams and the capsule protocol, so having in the DATAGRAM capsule section makes sense to me.
It about the interaction about http datagrams (section 2) and the capsule protocol (section 3). There is nothing related to datagram capsules (section 3.5) in this paragraph. I guess you could just add a new subsection 3.6 if you prefer to have it at the end.
LGTM

Related discussion:
text: An intermediary can reencode HTTP Datagrams as it forwards them.  In other words, an intermediary MAY send a DATAGRAM capsule to forward <del> an HTTP Datagram which was received in a QUIC DATAGRAM frame, and vice versa. </del> <ins> an HTTP Datagram that was received in a QUIC DATAGRAM frame, and vice versa.  Intermediaries MUST NOT perform this reencoding unless they have identified the use of the Capsule Protocol on the corresponding request stream; see capsule-protocol. </ins> Note that while DATAGRAM capsules that are sent on a stream are reliably delivered in order, intermediaries can reencode DATAGRAM