I told you how it is relevant. Groups are components, and so have the same limitations in addition to their limitations (as mentioned above.)
But … their basic limitation of their definition being hidden from the component manager might be an advantage in this scenario.
And this is the very difficult issue.
I think we have discussed this in the past when talking about the problems with Dynamic Components (and also with what we are seeing with the beta Live Components.) In that discussion (which is probably in the DC category,) I think I also remember myself proposing that perhaps groups could also be used similar to what you have just proposed.
See this old topic …
… and this topic is the one I remember, that both @Anssi and I were proposing that similar but unique DCs be held together in some sort of transparent “collection” …
Currently, with DCs, it’s extension automatically makes instances unique when any nested object is hidden via the “hidden” dynamic attribute. (But, yes, that then breaks the sync’ing of the common geometry.)
And since it is a no-no to modify the proprietary DC code objects, this would mean a whole new component engine. It likely has not yet been done because of the amount of investment (ie, it is a very large code project to create something the feature size of DCs or LCs.)
The Live Components are doing this now, but the instances have unique generated geometry that is not in sync with other instances. We’ve told them we need them to be part of “collections” that can have certain properties (like material) synced and settable across the whole “collection”.
Anyway, … back to existing extensions. There have been some attempts at parametric components extensions, but I have not tried them myself. (So, I don’t know if they’ve tried to crack the hide nested object situation.)