See for example the archetype openEHR-EHR-COMPOSITION.referral.v1.adl, which includes a PARTICIPATION in context.participations, but does not include an at-code, because PARTICIPATION is not LOCATABLE. However, the ADL 1.4+ rules state that any member object of a multiply-valued attribute must have an at-code, in order to distinguish it from sibling objects (even if added later).
Possible solutions: it might initially appear that an object can have an at-code in an archetype even if not LOCATABLE in the reference model, however the data will not carry the at-code, and the object cannot therefore be properly matched to an archetype node later on.
Agree that this is a problem
Would be helpful to add PARTICIPATION inheritance to Locatable to constraint the vocabulary used for Participation fields.
The downside of this is we now need to specify a name for each PARTICIPATION. The need to specify a name on every LOCATABLE object is a real overhead and adds no value in most cases.
IMO that is true only for archetypes that specify Participation and it is mandatory. In other cases the participation might not appear in data instances.