Lucas, Assuming that we have the necessary language about QUIC APIs, as I've just proposed, to enable something in future, then I personally have no use cases or strong objection to punting. It is somewhat annoying to have a draft for priorities, datagrams, and then priorities-with-datagrams, but if writing the last bit will be a struggle (which I have no informed opinion on) deferring it is probably the right decision.
Now descending into the weeds: > It's easy to say this. The difficulty comes, as an implementer, with knowing what to actually do with the information. Concrete example, if a client signals "incremental false" does a server send all streams as FIFO and then all DATAGRAMS as FIFO, or does it look at DATAGRAM flow creation order No, I think the DATAGRAMs correspond to a stream and they go with the STREAM frames in with priority. Whether one delivers STREAM or DATAGRAM first within a particular stream maybe doesn't need tight specification; if we do, I'd say STREAM (if for no other reason than to deliver the headers) and then DATAGRAM, unless STREAM is being flow-controlled. As datagram flows don't have a 1-to-1 mapping with requests and responses, I think streams are the correct abstraction for datagram priority, not flows. If there are multiple Flow-IDs associated with the same stream, they all get grouped together for priority purposes.
