Pipelining was a well-intentioned feature which didn't solve the core problem: namely, that a big or slow request can block you from doing anything else for a really long time unless you open another TCP connection.
And this "head of line blocking" problem... who said it was a problem, Google? In reality you have 4 or more connections that automatically work like spread spectrum where most resources aren't stuck behind a big or slow request. But even if this was an actual problem, a simple hint in the HTML that the resource might take a while and to put other ones on a separate connection would optionally solve this problem, and with almost no extra complexity.
Can you point to that?
It's a bit sketchy on the details and data - reading it I certainly end up with more questions than answers
Hmmm, starting to use it seems like less effort than introducing an entirely new protocol.
> the core problem: namely, that a big or slow request can block you from doing anything else
Why is that the core problem?
Head of line blocking leaves the network idle, and one of the key factors to good front end performance is to overcome network latency and start using the network / growing the congestion window as soon as possible.