Yes I fully agree, this can definitely become a problem. I think though we're stepping on premature optimization territory. We can always add/migrate to the maintainers tag later if it ever becomes necessary, right?
Discussion
I thought about this one as it becomes very difficult to add later as we are building a bazzar rather than a cathedral. The incentives won't be there to add it later.
Without this feature most app teams will create a keypair for the app and share the key between maintainers. This will build up trust and an install base. They won't be incentivised to abandon threre existing pubkey which has built up trust and an install base. They won't have a mechanism to make it easy for users to switch to the new model. And unless 90% of the client support it they will degrade the upgrade experience for a proportiom of their users.
Clients won't be incentivised to add support because 1) there client is working 2) they are busy with other things 3) existing app teams aren't asking for it becuae of the above incentives 4) they are waiting for other clients to add support first
Sure, it's all about striking the cathedral/bazaar sweet spot. Can't something like FROST solve this or do we need to bake it in now? A few weeks ago nostr:npub18z6qteykzjp4czp6uypnnrz3qv2u8gpkdnazwy2ejhneayj9zpvqzvn6df posted videos showing nostr multisig
As I understsnd it, in an n/m you can only remove n-1 participants which wouldnt meet our needs.