Yes and no. If you're using 5011 as the model, and you have two keys as trust anchors, and one associated private key is compromised, then there really isn't a lot of difference in proceedures. You revoke the compromised key, and start the process of getting a new key accepted as a trust anchor.

The emergency thing shows up when all of your existing trust anchor keys are compromised. And there really isn't a way to deal with that contingency, planned or not. Basically, if A[public] is your only root trust anchor and A[private] is compromised, you're dead in the water. You can attempt to add new B[public] keys to the trust anchor set using 5011, but there's a good chance that your attacker is attempting to dothe same thing. If the attacker revokes A[public] by setting the bit and signing the root DNSKEY RRSet with that key, what probably happens is that ALL data without subordinate trust anchors is considered invalid by resolvers and rejected.

5011 gave very specific guidance on what needed to go into the root DNSKEY RRSet to avoid this case - but the current RRSet and Trust Anchor set are missing the second KSK.