You can pin in software you distribute. If you're big enough (top 100 websites mostly), you can ask browsers to pin certs and they may included it in their preloads.

> And what happens when you want to switch?

You have to update your pins and then wait long enough that you don't mind losing users who never update their software. When it's just in software you distribute, you can change hostnames in new versions and use the new CA for new versions and the old CA for old versions...

For web browsers, there's not a reasonable way to make a nicer transition. You have to serve old certs for old pins, and TLS handshakes from browsers don't include enough information to know if the client has an old pin or a new pin; or at least, mostly they don't --- if you get your pins changed and the browser TLS stack changes so the handshake changes after that, maybe you can use that... when sha1 certs were phased out, it was somewhat popular on high volume sites to look at the TLS Client Hello to decide to serve a sha256 cert or a sha1 cert.

DNS CAA only pins issuance, not acceptance; clients can not check if the CA that issued a cert was listed in DNS CAA at the time of issuance, and they do not check if it's listed at time of presentation. I'm pretty sure issuing a cert contrary to a CAA record is a mississuance and would result in sanctions from the CA/Browser forum, but clients would still accept the cert until it's revoked.

There was briefly browser support for site initiated pin on first user (HTTP Public Key Pinning), but it got dropped as mostly no one was using it and it was easy to get wrong and break your site.

https://kagi.com/search?q=dns+CAA CAA is one way, but you can also pin the actual certificate or certificate chain (which has its downsides, mind you).

Because it makes you only as secure as the the LEAST secure CA. Such as the really bad ones that don't use Hardware Security Modules.