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.