I think that middleware boxes will still find some way to make our lives miserable next time we try to upgrade— this seems like another instance of "build an idiot-proof system, and the universe will just supply a better idiot"— but this is still a great idea. This is so good I want to start doing it with my company's internal stuff.
Company internal stuff generally isn't facing as hostile an environment as HTTPS.
The famous "Alice and Bob After Dinner Speech" mentions
"Now most people in Alice's position would give up. Not Alice. She has courage which can only be described as awesome. Against all odds, over a noisy telephone line, tapped by the tax authorities and the secret police, Alice will happily attempt, with someone she doesn't trust, whom she cannot hear clearly, and who is probably someone else, to fiddle her tax returns and to organize a coup d'etat, while at the same time minimizing the cost of the phone call.
A coding theorist is someone who doesn't think Alice is crazy."
HTTPS is like Alice. In cryptography a theoretical attacker is often given seemingly outrageous abilities, like they can send you huge numbers of arbitrary messages to see what happens, they can time everything, they can see messages you were sending and try sending other messages that are just a tiny bit different, they can collect your messages and re-send them later, and so on. In many systems a real attacker would struggle to pull these things off, but in HTTPS thanks to things like cookies and Javascript it's actually not difficult at all.
Your internal stuff almost certainly doesn't have arbitrary clients running code from arbitrary other participants like the Web does. It also almost certainly doesn't have a dedicated reliability team who can go change everything every six weeks to keep up. If you do such changes every six weeks for a few months, then get bored and stop, the last set rust shut and you've gained nothing. Google is essentially promising their teams would undertake to carry on indefinitely.
Google essentially proposes an artificial Red Queen's Race, with the goal being to tire out middlebox vendors and/or their customers and have them choose to exit the race.
(Let's Encrypt creates random protocol extensions on every connection in order to ensure that clients are tolerant of protocol extensions that they don't understand. Breaking changes to the protocol, on the other hand, will be served from a separate API endpoint.)
