I don't think it's that different. also there are many different ways to design this, not all suffer from the same issues that you've described. you seem to have given up on this. that's ok but I hope others didn't.

Inkan displays exactly the same profile picture for my signer key as all other Nostr apps do. Here it is:

Inkan

Inkan web client

At the same time, the posts I am making are also getting attributed to my master identity, which you can see here:

Inkan

Inkan web client

There is nothing nefarious or destructive about it. You can literally delegate down from a master key to your regular Nostr key and keep using your regular Nostr key as usual across the Nostr ecosystem. That's what I'm doing right now. You'll just have gained the benefit of a master identity which can, in case your current Nostr key gets compromised, revoke it and replace it with a new one.

an embedded, revokable attestation *is* immutable. it can be disavowed, but that's not mutation

I read about 15 or so proposals on this. All of them suffer from the same issues. So, it's not that I have given up. We just run out of ideas. Even the ideas that delegate identity to a separate protocol fail to address the same issues. That's why I am investing so much in WoT. I don't think identity can be solved by anything else at this point.

How do you place said attestation in replaceable events that are mutable by design? Do we now have to deal with revocation of revocations through replaceable events by attackers?

For the record my proposal would be completely backward compatible with the current impl of nostr. Clients would simply choose to honor and build trust trees if they chose. Otherwise keys present as individuals as they always did. The published delegation events produce the trust tree. Follow them, get the trust.