For sure, excited to hear you're going to be there!
I have a different design philosophy I think, which is to create robust abstractions and then limit them at the application layer. This bites me sometimes, but if there's follow through I think it works.
So nip 87 is "the kitchen sink plus some other stuff", but in practice only some parts will be supported (similar to the protocol itself). This means that you get greater interoperability, because multiple features work based on the same abstractions.
The flipside of course is that if you overload an abstraction, you have contention over semantics. But nostr's kinds basically solves that problem and as far as I understand the problem we need only two kinds of encrypted messaging support in nostr: one-to-one messages (scalable to groups using duplicate messages), and many-to-many messages (scalable using a shared key).
Anything in addition to those (moderation, administration, relay selection) can be rolled into either abstraction as an independent component, I think. Of course, my entire approach may change, as I shift back to exploring how relays can solve some group stuff on their own, without encrypted channels.