You can't "simply" do that: a long cache period pins CAA. Of course that makes it the same, and with the same problems.

What I'd like to see is the ability to use and utilise multiple TLS certificates and host keys on the same session so that all the keys could be rotated/phased in-band with cross-signing providing the authority.

Seeing any mere change in the signers faster than (say) 30 days should allow the browser/client-stack to generate a warning that "google.com may be actively under attack please call this number on the old certificate, codeword banana-alpha-lima-lima-sigma". No need to cross-publish the keys, just cross-sign and don't forget what you've seen previously.

The browser would be able to take policy of simply never trust a certificate whose signer has changed (since phasing is possible), and it wouldn't then need to consult more public oracles (DNS, certificate transparency, etc, that leak privacy).

I'd also like to get that webauthn hooked back into TLS client certificates: If we had 1997 again instead of passkeys that also would've stopped this.

> The browser would be able to take policy of simply never trust a certificate whose signer has changed

This assumes that the signer's keys can't be compromised, and re-introduces the issues of key pinning that the WebPKI community has been pushing very hard to eliminate from its dependents. I don't think it's a workable solution.