"This isn’t a flaw. It’s how optional, backwards compatible features roll out." That's fair. And maybe this does remain a feature only used by advanced users. Though, I would argue that it is less likely to see widespread client adoption if it is expected to only be for advanced users, and widespread client adoption is the only way this becomes useful, in my opinion. Without it, users have to sacrifice a large chunk of their current audience in order to take advantage of the security benefits provided. Therefore, I could only see it being useful for new users who do not yet have an audience they would be sacrificing, or existing users who have had their nsec recently compromised, so they need to start over anyway, in which case their previous nsec would NOT be their root key. If wide client adoption happens, then I could see it being useful for more existing users. Not until then, though, and I don't see something that is currently not helpful to hardly anyone gaining support from client devs. But then, I am not a dev. I think @ hodlbod already chimed in on this, and had a similar criticism to mine, though more technically informed than me, by far. Maybe some of the others, like @jb55 , @Vitor Pamplona , @npub1n0st...lahe , @miljan , @hzrd149 , @Cody and others I am neglecting can chime in about likelihood of implementation by major clients, let alone widespread adoption by most clients, including the vast array of "other stuff" clients. As I see it, this would have a huge impact on Nostr interoperability for any user who moves to using a derived key, since some clients would act as expected and others would treat them as a separate user until the vast majority of clients were on-board.