I don't think this changes the dynamics adoption of QUIC. To Eric Kinnear's point earlier, I don't think we should have the illusion that we can reduce the number of networks that don't support UDP by holding back on anything.
The slippery slope argument of turtles-on-turtles is not a compelling one... I've been hearing that argument for 25 years, and we still seem to deploy things on top of things just fine. Layering is a state of mind, artifacts however routinely optimize common paths through layers.
Performance being poor IS the argument for endpoints not wanting to use QUIC on TCP. But it's a fallback anyway where function is more important than performance.

Overall, I am supportive of this. Primarily we already have the plethora of things to support because we split HTTP/2 and 3 based on underlying transport, since the assumptions of the transport service are different. This proposal seems to provide a unified surface above the transport (QUIC) where the services offered below are different (UDP/TCP). Unifying this is useful. This isn't going to be simply (as Ted noted), but the complexity might be worth it.

Meeting Chat Log		QUIC (quic) WG
Title		Chat Log IETF119: quic: Wed 09:30
Session		Materials
Last updated		2024-03-20

Chat Log IETF119: quic: Wed 09:30 chatlog-119-quic-202403200930-00

Chat Log IETF119: quic: Wed 09:30
chatlog-119-quic-202403200930-00