Well, I thought about "Relay Types", which is an improvement. But the question here is if we should keep calling them "Relays" at all. I actually think Relay is the correct technical name for what the thing is doing. But UX-wise, we are calling too many different things "Relays". And that doesn't help anyone. The main issue is that people are adding Community Relays as Outbox Relays... Because everything is a "Relay".

Well, community relays are just a relay that exhibit particular behaviors and restrictions; any combination of those (and other) behaviors and restrictions could be atomized and expressed programmatically. How those behavior and restriction flags are defined could be tricky, but it would be far easier to maintain an array of flags in say NIP-11 than it is to constantly update the named properties (such as restricted writes) or to try to group those features under some atomized property. The methodology of using feature flags instead of named properties was one of my motivations behind signaling that we might consider splitting NIPs, which IMO should be specifications that affect relay behaviors from data schema specifications (what I called NAPs); they have different implications, different draft tracks and require different levels of scrutiny. IMO they are relays, as they fit the technical definition, but we shouldn't call everything just a "relay" and there needs to be a way to disscern one from the other. IMO your work on relay types was a good start to this.