@thomas.beale for context here I mentioned an idea for an”extension* keyword for ADL
That’s for defining an extra attribute on an existing class. The same or similar keyword could be used to define a class (which could inherit from an existing one). All that is the a additive aspect that could be built from scratch on top of a base metamodel, because you need, at least, to know what a class, attribute and relationship is.
Then the corresponding classes to the AOM should be added to support those new ADL constructs.
If tools, utilities, CDRs and apps can interpret those, then you can “compile” (flatten) any set of different levels of definition into one final “OPT” to be used in software, with full tracking/traceability off all the elements used to generate that final definition, and using a single formalism can result on having a single/simpler/integrated workflow and simpler/less expensive software. Today we have different flows to manage different formalisms at different levels, with different pieces of software, and the is no capability of extending the RM in a formal/controlled way (which IMO is a must today, specially when interacting with other standards like FHIR which allows extensions to the base resources).
Besides the claims case I mentioned, we had another project where they wanted to analyze appointment scheduling data following the openEHR processes, for which we also (ab)used the composition, and I would have preferred to formally extend the model.