Change:
with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Endpoints MUST NOT send HTTP/3 datagrams unless the corresponding <del> stream's send side is open.  If an HTTP/3 datagram is received and its Quarter Stream ID maps to a stream whose receive side has already been closed, the receiver MUST silently drop that datagram.  If an HTTP/3 datagram is received and its Quarter Stream ID maps to a </del> <ins> stream's send side is open.  On a given endpoint, once the receive side of a stream is closed, incoming datagrams for this stream are no longer expected so the endpoint can release related state.  Endpoints MAY keep state for a short time to account for reordering.  Once the state is released, the endpoint MUST silently drop received associated datagrams. If an HTTP/3 datagram is received and its Quarter Stream ID maps to a </ins> stream that has not yet been created, the receiver SHALL either drop that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream.

Discussion:
H3 datagrams are associated with a stream, so it makes sense that it is only valid to send DATAGRAMs before sending the stream FIN. These packets may be received out of order however. What should receivers do with these packets? The simplest action for the receiver is to drop any datagrams received after FIN, but I can imagine applications where the receiver would prefer to allow them to be processed for some time. Should the draft offer guidance for this? The answer might be different if we use Flow IDs as connection scoped identifiers or the 2-layer approach (Stream ID+Flow ID) discussed at the interim.
I think this might be a case for "MUST NOT send datagram after the stream is closed for sending, MAY ignore datagrams if detected they are received after the stream is closed." The challenge I've seen for implementations is that the stream read and datagram read functions operate independently. Its hard to correlate any state or actions between the two. In my case, ACK'ing a packet containing a FIN doesn't mean anything about how the receiver application will read the stream data.
Thanks for filing this. I'll add text to address this after we switch to the two-layer approach (assuming that becomes official WG consensus)
The proposal here was receiver MAY drop a datagram after receiving FIN, but the merged PR has receiver MUST drop. I prefer MAY, since I can envision a use case where the receiver would rather wait for a period to allow wayward datagrams to arrive, rather than declaring everything lost because of minor reordering. Is there a strong objection to changing this MUST to a MAY?
NAME Can you provide an example of a use-case for not dropping a datagram which arrived after the stream was closed? I'm failing to imagine an application that would benefit from this.
"Naive Partial Reliability" or NPR: Client sends a request to the server indicating it is willing to accept the response body of an HTTP message over DATAGRAM rather than in the stream. Server sends the headers on the stream, and a marker indicating the response will come via DATAGRAMs (registering a context for this perhaps) Server sends DATAGRAMs containing the response body (and offsets) Server sends stream FIN The client receives the stream FIN before the DATAGRAMs because of reordering, and assumes all response body was lost.

Datagrams arrive at client shortly thereafter and per are dropped.
HTTP/2 kind of has some similar issues. It makes statements like for a short period after a DATA or HEADERS frame containing an ENDSTREAM flag is sent. Until the remote peer receives and processes RSTSTREAM or the frame bearing the ENDSTREAM flag, it might send frames of these types. Endpoints MUST ignore WINDOWUPDATE or RSTSTREAM frames received in this state, though endpoints MAY choose to treat frames that arrive a significant time after sending ENDSTREAM as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. and elsewhere prioritization state for a period after streams become closed. The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values.
OK this makes sense to me, I can tweak the text to allow keeping stream state around for slightly longer.