This doesn’t sound particular scalable, if we imagine more group implementations coming - and what if I want to support both FEP-1b12 groups and another group implementation at the same time? I’d need to decide on the group types according to some ad-hoc rules of which groups have which properties? Again, I really think an explicit signal is preferable here.
To handle Activitypub it makes more sense to use optional fields, handling those your software understands and ignoring others. Same for incoming activities, handle the ones you understand and ignore everything else. Basically duck typing as @silverpill also mentioned. That way there is no need to know the exact type. Anyway I think at least 90% of Activitypub groups use 1b12, so you can assume that if there is no other indicator. And like I said, it would be impossible to add such an indicator to all existing instances (there are Lemmy instances like beehaw.org which havent updated in years).
Strictly speaking it is only adding a type (and retaining the existing
Grouptype), which should be totally backwards-compatible. Thetypefield has always been polymorphic and any implementation should be prepared for the possibility that there is more than 1 type in that field.
It is part of the Activitypub standard, but not supported by Lemmy. Just like many other parts of the standard are not supported (eg client to server Activitypub, question activity, etc etc).