You've got it backwards. The final problem with HTTP/2 couldn't be solved by the application layer protocol alone, so "intermingling" is a "not-even-wrong" comp

You've got it backwards. The final problem with HTTP/2 couldn't be solved by the application layer protocol alone, so "intermingling" is a "not-even-wrong" complaint -- if you transported a large JPEG and an HTML page over the network in an HTTP/2 stream, a lost packet in the jpeg file would cause the html stream to potentially stall until it was corrected and finished, even though you can load both concurrently. This effectively causes head-of-line blocking on what should be a concurrent system. So a primary attraction of HTTP/2 is effectively defeated and possibly even made worse; it is a behavior instituted by TCP, there's nothing you can solve it with. QUIC was "intermingled" because it exactly solved this problem at the transport layer, the only place it can be solved. They couldn't just introduce any random thing, and no other protocol existed, so they ratified QUIC independently as its own protocol and applied it to HTTP/3 at the same time. They had to introduce a new standardized transport if the hope was to solve the HOL blocking issue. If you "dis-entangled" it you'd just have HTTP/2. The new transport protocol is the defining characteristic. Furthermore it all would have been pointless to define QUIC as a standard without actually applying it in practice, in anger, to real workloads. Which is exactly what multiple stakeholders in the process did throughout the multi-year ratification process. What are they going to do, define QUIC, sit on their thumbs for 5 years and cross their fingers hoping someone else tries it? There are other factors like most of the involved stakeholders had previous experience watching with other attempted standards in similar veins like TCP Fast Open die on the vine. That also influenced decisions like using UDP for QUIC's transport (and the ever present discussions about middleboxes.) Actual experience indicates most low-level protocols have ossified badly or are handled very poorly, including TCP and UDP except most things can handle those, so moving the transport layer into the application stack is seen as providing actual agility needed to respond to issues like the HOL blocking issue. That's how they revised the protocol several dozen times over the years; applications are actually fairly agile. Now you could argue these people should have discovered that issue when designing HTTP/2, but "Why didn't this thing get discovered and found out?" is always a weird complaint. Why would you expect everything to be found out early? I just can't answer that complaint honestly. Weirder things have happened than "Some engineers missed something." Many people seem to hold some unwritten belief that if a protocol is defined as, say, an application layer protocol at one point, then it can never ever redefine its parameters to be anything beyond that. It can never become a transport protocol, for example, or have the two be mandated together, despite decades of experience suggesting that might be a fruitful path for many technical reasons. But there's no random rules of the universe defining what a network protocol looks like. It can be whatever we want it to be. Humans define this, there isn't like a book of 10 commandments out there written by God. There is also no necessary indication that HTTP 1.1 sticking around for so long versus HTTP/2 necessarily meant it was the best among all options, by the way. We abused it a lot for many things. Being around for so long could also mean we were just bad at enacting change; certainly browser monocultures have made change easier for better and worse, on that note. But the whole HTTP/2 and HTTP/3 process has been about 13 years on its own if you count it as starting with SPDY. It's not like there's 200 years of precedent for how long it should take.