#3: probably not possible, but necessary to avoid building up technical debt that's going to bite us later on.
Discussion
#3 can be reworded to ‘focus on fewer nips, seeking better outcomes, with greater collaboration’.
Often NIPs are read or worked on by five or so people, yet impact dozens of devs. Very commonly they don’t extract out the general use case, but target a single dev’s target problem today.
A good example is the server AUTH spec. It was never intended for general webapp or api login. Targeted websocket messages by adding a new command (Nostr literally only has four.. so adding a fifth is significant).
That NIP was so focused on a way for DMs to only be queryable by sender/receiver + pubkeys, that it excludes web app login, API auth, and all use cases where you may want or need to prove you hold the private key - like subscriptions or private relays.
If more a collaborative process was happening, it could have been generalised, people have realised websockets use HTTP to connect and supports headers, and we can create a common event kind that works for many use case, and apps can implement once and one NIP.
Devs get very excitable and tinker (including me). That’s important and valuable.. but we need some layer of collaboration on top of that.