Original text:
it RFC9002.  The sender implementation MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the application). <del> Implementations that use packet pacing SHOULD support delaying the transmission of DATAGRAM frames for at least the time it takes to send the paced packets allowed by the congestion controller to avoid dropping frames excessively. </del>  Implementations can optionally support allowing the application to specify a sending expiration time, beyond which a congestion-

Reviewer comments:
I've dramatically simplified what we say for pacing now, to just call it out and the fact that it can add slight delays. NAME NAME thoughts?
I like the latest text, it's clear about things that are required, but it doesn't provide advice that we haven't tested. LGTM.
I am having trouble parsing this. I think that this is saying that if you have a pacer, then an endpoint might delay DATAGRAM frames to avoid overriding the sending rate of the pacer. However, this seems to imply that the maximum delay imposed here is the inter-packet interval of the pacer. I think that is a bad assumption, even if it might be a simplifying assumption that some implementations might choose to adopt. In some cases, the pacer interval will be too slow for the application (for low BDP, high RTT connections especially) or in some cases the pacer interval might be short enough to allow multiple intervals before dropping the packet (for high BDP, short RTT connections). The goal should just be to avoid deferring DATAGRAM sending indefinitely, with controls over any delays being available to applications. Maybe:
I think the goal here was to prevent implementations naively dropping DATAGRAM frames anytime they couldn't be sent immediately, which would be a pathologically bad case when a packet pacer is being used. But good point that this should be clarified.
Early in our VPN implementation, we sent QUIC datagrams without any queueing, assuming that if a datagram gets dropped, then we exceeded the cwnd (and thus the estimated channel capacity), so it would likely not reach the peer anyways. In practice, this turned out to be a terrible idea that lead to underutilization of the channel; our implementation always does pacing, so if you don't queue the datagram, it will get dropped unless it just happens to fit into the current pacing quantum. Because pacing is RECOMMENDED for QUIC, I believe some form of queueing should be RECOMMENDED for datagrams, otherwise the users risk running into the same hard-to-debug problem that we had.
I think adding a note about pacing to the "Congestion Control" subsection makes sense to me.
+1, if you're in the bucket of implementations that have insight into their pacing algorithm, it should be reasonable to expect that you'd avoid dropping your own datagrams unless you make a queue and then build up too much in that queue.
Small wording nits around "allows it" twice, but I don't have a radically better wording handy so looks good :)

Revised text:
it RFC9002.  The sender implementation MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the application).  <ins> Implementations that use packet pacing (Section 7.7 of RFC9002) can also delay the sending of DATAGRAM frames to maintain consistent packet pacing. </ins> Implementations can optionally support allowing the application to specify a sending expiration time, beyond which a congestion-