The problem is important, the difficulty is that because we directly link to pubkeys rather than some proxy identifier (like DIDs do), there's no way to unilaterally migrate links to your key. In other words, people follow your key, and there needs to be some kind of support for either migrating references to keys, or translating an old key to a new one.

The former approach would be marginally easier to accomplish, since it would only require a single client to implement migration. However, users would all have to periodically visit that client in order to perform migrations. Building this into a "core" client like a signer might allow users to run migrations in the background, but even then, only replaceable events could be migrated; kind 1 references would be permanently broken.

The latter approach is more complete, but would require EVERY client to implement complex logic for discovering and validating migrations, potentially creating dependencies on timestamping servers for sequencing events reliably. Right now, even if there were a standard that worked, it would be unlikely to get adoption. What we need is a migrate-keys-sdk that client developers can add to support both migration and key proxying. Someone needs to really own this because it requires an incredible amount of effort.