Change:
3.3. <del> When an error occurs in processing the Capsule Protocol, the receiver MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed </del> <ins> When a receiver encounters an error processing the Capsule Protocol, the receiver MUST treat it as if it had received a malformed or incomplete HTTP message.  For HTTP/3, the handling of malformed </ins> messages is described in H3.  For HTTP/2, the handling of malformed messages is described in H2.  For HTTP/1.1, the handling of incomplete messages is described in H1.

Discussion:
Explicitly replicates parts of H2 and H3 CONNECT stream definition to make it clear what frame types are/are not allowed on a stream. Mostly anything else can't happen but if it does, approach error handling as if it were like a malformed message (I.e whether to terminate the stream or whatever).
Found it and fixed, thanks Martin!
In Sec 3.3: When an error occurs in processing the Capsule Protocol, the receiver MUST treat the message as malformed or incomplete... there are 2 other reference to malformed "messages" as a result of Capsule shenanigans. but in the introduction it says that datagrams "are not part of message content". So what is "the message" that should be treated this way? I think you mean the Request or Response that initiated the Capsule protocol. If that's correct, a more precise phrasing might be "MUST act as if the message that initiated the capsule protocol was malformed".
Agree we can probably tighten things up here. For one, the definition of "data stream" in 3.1 presently says In isolation, this statement leaves it a little unclear whether trailing headers can appear after the data stream. In , that defines how CONNECT works, things are a lot clearer: My working assumption has been that data streams have similar requirements, but we don't explicitly state that anywhere, which is not great. If we tighten that up then it should become clearer that, once the capsule protocol is successfully negotiated, the HTTP message ended after the first HEADERS frames. We would still expect endpoints to apply some rules to frame processing on these data streams, and if there was a problem the data stream is malformed. Today we equate malformed data streams to malformed requests, and therefore delegate the handling of such problems (reset stream + error code) to the respect section in H2 or H3. I wonder actually if we should just state some explicit stream termination requirements. This does not change the actions that endpoint might take, but it does clarify the circumstances under which they should happen. I'll prepare a PR for this to help illustrate my thinking.

To summarise: 1) If an endpoint screws up meeting the requirements of request or response field sections that bootstrap a capsule protocol instance, that is clearly a standard "malformed message" 2) If, after a capsule protocol instance has successully been created, an endpoint screws up anything on the data stream, that does not seem like a "malformed message"
I can understand the impulse to avoid the term "stream" because then you're in the business of defining the behavior per HTTP version, but I'm sure you'll come up with some good language.
+1 to what Lucas said above