Just going to give a bunch of feedback and hopefully something of value to ya 
Yes, I agree. I think that I was thinking too narrowly on the concept. In definitions of “Organization” (e.g. Free Dictionary) there’s things like “the state or manner of being organized” which is as broad and generic as can be.
In my (probably naive, as I’m no expert) diagram, see embedded in this post , I went from the Group as having the relationships to define the social fabric of its Community organization (mostly to limit impact and scope of the extension). In another thread on a Community AP extension, particularly this post by @lynnfoster shows that Valueflows (which has been implemented in a #software:bonfire module), defines the relationships at the Actor level. And that may be a more appropriate design after all, giving largest amount of flexibility.
Then, when just talking about Group… there’s 2 parallel discussions ongoing about the same topic of standardizing their design, and formalizing that in (one or more) Fediverse Enhancement Proposals, or #standards:fep. These are:
When I talk about “Community” and “Community has no Boundary” as a paradigm, I am solely interested in being able to express richer associations in the social graph than we do today (the relationships aspect). In this it is the ‘space between’ otherwise fragmented and dispersed Groups that is of most interest. The ability to tie those together in meaningful ways and thus “weave a Social Fabric”.
(I was also pondering whether relationships might contain Actor objects directly, besides only allow for Relationships. That may ease implementations where groups have just members, no other ‘organization’ to them than that, and seeing an Actor in the collection would then default to a member_of relationship)
Note that Moderation has nothing to do with all this. It is imho a wholly separate concern that is independent of a Community AP extension. In domain-driven design speak, Moderation is in a different ‘bounded context’ than Community. If you combine the two together, one might say you get a “Moderated Community”. A Moderation bounded context could undergo a similar standardization and have one or more FEP’s and/or Vocabularies defined that will guarantee a certain level of interoperability.
I am just mentioning this. Think you are already keeping things separate. We should just avoid that a Group means that by definition it should have this_and_that moderation features and admin_mod_member privileges, or something like that, in order to be interoperable.
(Btw, I wrote a separate topic on Federated Moderation: Towards Delegated Moderation?)
About “Decentralised Group”. I wonder if we can find a better term for it. After all, Groups as they are now (tied to an instance) with Relationships to other groups elsewhere on the fediverse, are already decentralized. Dunno such terms now, other than “Unbound Groups” or something like that. The way to set them free from their instance in this proposal constitutes a workaround for a broader limitation of ActivityPub to be addressed: ID’s tied to the domain via an URL.
Also wanted to point to a related FEP in process, by @grishka namely: FEP-400e: Publicly-appendable ActivityPub collections.
PS. In terms of notation… I don’t know if there’s some ‘standard’ way, but I see formats as Activity{Object} in use which to me makes it clearer that the activity wraps the object, whereas Activity/Object might lead to confusion if people read it as an ‘or’ or ‘and/or’ choice.