We could possibly manage this in a similar way in which we handle the "default" facets in the search manager at the moment. If we treat XML scripted aspects as "system property groups" (or some similar name) then it could be possible to still disable/enable them (as that could potentially still be a viable requirement).
If we end up rendering both Property Groups and XML Aspects in the same list of "things" to apply to a Node, then there would probably be an expectation to also manage them in the same list as well. It should be possible to view all aspects/property groups in the same manager list... we could always have an "include system property groups" check box in the same way as we have an "include system groups" in the Groups manager page.
The list of Property Groups should appear in the page that we create for managing Property Groups
I'm trying to reverse engineer what a property group is from comments on the recent product management office hours with Richard Esplin and the stories that are publicly available via JIRA. This seems like something where Alfresco will provide tools for creating custom aspects via UI tooling. It would be good to see stories that call out who will use these features and why they are important (I have some use cases in mind, I wonder what product management is thinking here.) Anyway I noticed the list of ways of distinguishing system vs dynamic vs property group aspects in this ticket and it occurred to me. Why not just have a base aspect that all property groups inherit from?
Bindu Wavell It's important to realise a couple of things here:
- Just because a user story is defined in JIRA, it doesn't mean that it's going to be worked on
- Also, just because a user story does exist in JIRA, doesn't mean that there aren't other user stories that haven't been created in JIRA yet that might get worked on first
So we may yet create more user stories around Property Groups.... we're using Agile so we could be creating new stories right up until the last sprint, so don't expect there to be a comprehensive set now. We're also taking an iterative approach to development, and these stories relate to a first pass based on what we can easily achieve now.... so what gets implemented for this user story may yet get replaced by a later story (e.g. if we decided to make more in-depth model changes or updates to how the Repository handles the model)
In terms of your specific question.... that might be one approach, however - just inheriting from a base Aspect class doesn't prevent bootstrapped classes from also extending that class, sure - it might be a silly thing to do, but it wouldn't guarantee an Aspect was a Property Group.... anyway, we have more questions than answers at the moment I think 
@ddraper, completely get all of your caveats.
There were really two points in my comment. First was that there are a bunch of stories about an epic called "Property Groups" but there does not seem to be a definition of what these are, what business problems they are intended to solve, etc.
As I was attempting to infer internal discussions/thinking based on public stories... ugh (better than nothing.) I saw this list of ways of flagging information on an aspect. I had not seen anything that would indicate that a Property Group (whatever that is) is something that should not be defined through bootstrapping. So my second point was that you have a way of flagging aspects now via inheritance...
Setting Fix Version for first release