Sure, if you want, plenty of usecases for that. And if you want a new MUX-like protocol that enables "hey I'm gonna open a new stream that authenticates this other way" you can. But I see no reason to tie an entire transport to 1 identity or anything like that at the base level.
You appreciate that "Sure, if you want" is more RFC 6919 than RFC 2119?
Let me give you a concrete case:
I have a client that has some 1:1, but primarily it has several chatrooms. The network is what I'll describe as "dodgy" - it's low bandwidth, high latency, and has high degrees of packet loss occurring in bursts.
When I send to a chatroom - or receive from one - the packet might therefore be lost, and need retransmission. When this occurs, all other stanzas occurring afterward need to wait for the missing packet to be retransmitted successfully.
QUIC addresses this by allowing multiple streams, so by following this architecture and sending stanzas which are order-independent on different streams, I could change the last sentence to be qualified: "... all other stanzas to the same chatroom ...", which is much better. On networks which are not "dodgy", it's still useful to any C2S connection.
But the only way to accomplish this in the XEP is to open multiple independent client streams within the same connection, which gives little to no advantage over simply opening multiple connections, and - at least in C2S - seems very niche. Introduce Carbons (and we must introduce Carbons) and it's actively harmful. In S2S, we could open multiple streams, one for each domain pair, as long as the TLS certs hold. But we can already do that via piggybacking and bidi, anyway - the advantage to S2S here is to avoid the HoL blocking, and that's very useful indeed. But, it could easily be made better by splitting channels based on bare-jid pair instead of simply at the domain-pair level, which is what I want to do at the C2S level as well.
To my mind, HoL blocking is the primary use-case for multiple streams, and supporting multiple authenticated entities via the same connection seems problematic, and gets wildly complicated when we want to (for example) use additional streams for media, or file transfer, or ...
So, summary: Authentication should be tied to a QUIC connection, not a QUIC stream, and we should be using streams to reduce HoL blocking.
I'd appreciate other people's view here.
Dave.