Change:
silently drop that Capsule and skip over it to parse the next Capsule. <del> By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx (Successful) status code. </del> <ins> By virtue of the definition of the data stream: The Capsule Protocol is not in use unless the response includes a 2xx (Successful) status code. When the Capsule Protocol is in use, the associated HTTP request and response do not carry HTTP content.  A future extension MAY define a new capsule type to carry HTTP content. </ins> The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields.

Discussion:
This looks ok
I find the difference between HTTP 1.x and HTP/2 vs HTTP/3 when an endpoint support QUIC datagram quite worrying. So as capsules are sent instead of the message body in requests and response, for HTTP/3 when one have QUIC datagram support a method can be defined to use both the reliable body as well as HTTP datagrams. This is not possible over HTTP/3 when the QUIC stack doesn't support QUIC datagram or for HTTP 1.x or HTTP/2. I think this makes it very hard to define something that will just work. I Think the easy fix for this is to just define in addition to the Datagram capsule a body capsule that carries a fragment of the body, so that one can send over an upgraded path both parts of the body as well as the HTTP Datagrams. The fact that the Capsule protocol doesn't give feature parity even for HTTP/3 is deeply worrying in my view. I can understand how this has not come up prior as the existing HTTP methods that been targeted by this mechanism, i.e. Connect results in that the data stream becomes the capsule streams. However, if some other HTTP extension that using Extended Connect are used, then the need for both body and HTTP datagram could arise.
Successful CONNECT and extended CONNECT requests convert the request into a data stream, those bytes cease to be HTTP "content" (the term we should be using instead of "body"). Supporting HTTP content over capsules sounds like a sure-fire way to introduce security bugs. I don't see any reason to do that as part of this specification. Future extensions would need to do the security analysis and probably find that there's a better design to be had.
Okay, but then I think the scope of this extension needs to be made clear to be limited to HTTP Extensions that has this semantics of converting the content.
I don't think that is a hard scope though, and if it is, it is something we need to think hard about and come to consensus on. Currently, if people find they really want to encode HTTP content in capsule, they are free to do so with all the risks that might entail. Being overly restrictive on future uses doesn't seem that helpful at this stage.
+1 to what Lucas said, a future extension is free to design "HTTP content over capsules" if it needs it.

We don't have a need for it today. The current scope is made clear by the text banning use of datagrams on requests that don't have known semantics for them
I am fine with a clarification that this support is currently not in scope due to reasons, and future HTTP extensions may be define additional capsule for content to enable this. I don't have a use cases, but currently HTTP/3 can support using both request content and HTTP datagrams simultanously.
OK documenting that HTTP/3 is special, as a consideration for future specifications to be aware of, seems reasonable to me.
+1. Marking this as editorial, we'll write up a PR to clarify that HTTP content can't be currently with capsules and that h3 is slightly special.
LGTM