Porting it to C would probably be overkill.
Yeah, modifiers on collections is basically doable now with Geom. Nodes.
So I think that select any object in a group, and it selects the group itself (parent) would be the most useful to design and implement. Since grouping would create an empty that would serve as a parent, we’d get that sweet sweet transformation goodness. It could also automatically resize the parent to fit the children, and allow for the display of the children to be turned off, so as to save viewport performance. Just playing around right now with parenting to a box empty with a number of objects gets exactly what I’m wanting in terms of grouping for transforms. Combine that with an easier way to move objects origin (on the fly moving an an origin, especially with snapping to vertexes, edges faces etc.) would be killer.
I don’t really see the practical difference from using a collection instance for this… if you want the group to be selected whenever you select a member, why even have specific members? As for the thing about moving origins, this probably does exactly what you want:
Grouping also ties into what I’d also like to develop regarding transforms, which is a more advanced duplication system. One where you could duplicate an object and transform it with rotation, scale, and translation at the same time, potentially with formulas if desired. Ideally it’d be also able to be a modifier / geo node (and potentially replace the array modifier).
Meh. Just use Python or Geom. nodes! If it is complex enough to need formulas or multiple transformations it’s not something you want a tool for, IMO.