First of all this isn't backwards compatible (because indexes, relay message validation and other things have to be changed), so if you're going to break Nostr entirely then it's better to make a new protocol that also tries to address other suboptimal parts of Nostr, like @Mike Dilger ☑️ is doing with Mosaic. But then at the same time you lose all the (small, but significant) network effect we have here, which to me isn't worth doing. Second, you create the need for these "disavowing" events to be reliably published (which cannot ever be guaranteed in Nostr) and they become the central part of Nostr, and you can't have that work reliably without a centralized sequencer (i.e. either a blockchain or a trusted operator), see for just a brief example of one of the many half-broken issues that can happen (I'm not sure this specifically applies to your idea, but I'm sure we can think of many variants). Now even if by miracle these disavowing events become reliably distributed then there is still the problem that now all clients and all relays have to store them and then check all incoming events that come with a locally valid attestation to see if their pubkey has been previously disavowed, forever. (I just came up with these issues now, later I can revise my opinion to either add more or retract these.) The other solution is to go the NIP-26 way and treat each key as independent, soft-linking them with attestations. That is more elegant in my opinion, but in practice it breaks too, because of issues like those described in this comment by @Vitor Pamplona:

GitHub

Linked Keys for Multi-Device Nostr · Issue #1810 · nostr-protocol/nips

Right now, using Nostr across multiple devices is a challenge. Either you: Share your master key (risky, especially on a phone). Use separate keys ...

Maybe you'll want to see also View article → although I don't remember what I wrote there.