Original text:
Flows lack any of the ordering or reliability guarantees of streams. Beyond this, a sender SHOULD ensure that DATAGRAM frames within a <del> single flow are transmitted in order relative to one another.  If multiple DATAGRAM frames can be packed into a single QUIC packet, the sender SHOULD group them by flow to promote fate-sharing within a specific flow and improve the ability to process batches of datagram messages efficiently on the receiver. </del>  3.

Reviewer comments:
in Section 2 "Flow Identifiers" it reads this to me seems to be in conflict with the opening statement if the flow-id is in the DATAGRAM payload, the transport is not supposed to be peeking at it. While it could be a nice (but a bit hacky) optimization in a real-world implementation, I feel like the RFC having it as a SHOULD is not ideal.
In my experience, in order to build a high performance implementation of QUIC, you have to leverage the fact that layers can share information to improve performance. Are you saying that you'd prefer not using SHOULD for this kind of optimization?
I think Luca might have a point. If we consider this as a feature that a transport provides as a service, I don't really know what the service provides. There isn't another transport mechanism that relies on the ordering, or an interoperable aspect (would the other side be able to detect this?). It seems this is an aspect more about the API that QUIC provides, which is going to be a rich field of opportunity. There could be benefits but I don't know if we need to use the SHOULD. We could probably relax the language and try to articulate the benefits or tradeoffs of packetization and frame bundling. For instance, batching might interfere with timeliness, and controlling that might start creeping into prioritisation territory. The more I think about it, the described behaviour about batch processing might assume the receiver behaves a certain way, which might not be true. Therefore this might not be a good default to recommend.
Fair enough. Perhaps we remove this for now, and add guidance once we have more implementation/deployment experience?
I can live with a less drastic edit, leaving the text in draws the reader attention to the idea that packing could be important. I'd be happy to put together an editorial replacement for review, and if we hate it, then drop the concrete recommendation?
Thanks Lucas, you framed it way better than I could. Also I believe that whether shared-fate within a flow is desirable or not may depend on the application.
I came here looking for the same information: Why is fate-sharing desired? Is there some background to this?
I think more implementation and deployment experience would help here. I can see cases like tunneling IP flows containing TCP where fate sharing is preferable, since it's better to lose two adjacent packets in one flow than one packet each in two flows. But it seems a bit use-case specific? Also, you would expect most TCP segments to be large enough you couldn't put two into a single QUIC packet.

Revised text:
Flows lack any of the ordering or reliability guarantees of streams. Beyond this, a sender SHOULD ensure that DATAGRAM frames within a  <ins> single flow are transmitted in order relative to one another. </ins> 3.