I think we have, with "WebTransport" a real opportunity to specify a proper
XMPP-native transport mechanism (no extra framing or use case specific hacks
like WebSocket or BOSH, full normal TLS support possible when implemented in
a normal client, etc) that happens to also work from browsers (and other
things like transit through HTTP proxies and HTTP reverse proxies... at
least if they support http3 smelling things).
I'm not sure what the "raw" QUIC advantages could be, but I would be
strongly in favour of making this a special case MAY with WebTransport
handshake support as at least a SHOULD level thing.
For all the purposes I need QUIC for (and Marc Blanchet, too), having full control over congestion control, keep alives, idle timeouts etc is important. Web Transport doesn't let you tinker in this way.
Also, Web Transport adds the HTTP/3 handshake, which is breaking the 0-RTT desire.
I think Web Transport might well be great for many cases, but I'm currently focused on low-bandwidth, high-latency, high-loss networks, so for my purposes at least I'm only interested in QUIC itself at this stage.
But, solving QUIC should mean that Web Transport is very easy.
Dave.