The issue here is different, the problem is: “given a RM object instance, how to get the corresponding C_OBJECT from the AOM for each node, if C_OBJECT siblings are indistinguishable”.
So you can have as many RM objects as you want added at runtime, if those sibling objects in the RM instance are constrained by a distinguishable C_OBJECT in the corresponding AOM (e.g. can be found by archetype ID + path), then there is no issue. The problem is having siblings in AOM (not in RM) that for the same archetype ID and path can match more than one C_OBJECT.
So in the case of the OPT I shared, there are sibling SECTIONs declared in the AOM which have the same archetype ID and path, and the only way of distinguish between those two is by the constraint added to the name, which should be present in any RM object that complies with the OPT. But, you could have (maybe not in the OPT I shared but in general) indeed many instances of SECTION added at runtime, for the same archetype ID + path + name.
What Thomas said, and I’m still processing since I work only with AOM/ADL/TOM 1.4 is in AOM/ADL 2 there is no need of the name constraint since if there are two sibling C_OBJECTs (AOM) with the same archetype ID + path, then one will be transformed to archetype ID-1 + path and the other one will be transformed to archetype ID-2 + path, so there is no collision. Still, your use case of adding multiple nodes in a RM object complying with archetype ID-1 and archetype ID-2 is supported without any issues.
The use case for the original issue is receiving a RM object e.g. via the REST API, like a COMPOSITION, FOLDER, PARTY or EHR_STATUS, and trying to validate that object against the corresponding OPT, so for each node in the RM object, the corresponding C_OBJECT from the template should be found in an unambiguous way, and with archetype ID + path (taken form the RM object’s nodes) alone is not possible, so the name should come into play as a workaround.
As said above, a simple solution would be to have a unique ID for each C_OBJECT in the AOM, and reference that ID from the RM objects, but that is not possible right now, in 1.4 and in AOM2, as Thomas mentioned, that is kind of encoded in the modified archetype ID, which doesn’t seem a very clean solution IMHO, I would opt for having a dedicated field for that instead of coding it inside the arch ID.
As a consequence of requiring the name to distinguish between C_OBJECT nodes in the AOM 1.4 structure is that when uploading an OPT to a system it SHOULD check sibling objects are distinguishable by using the name, since that pattern is not enforced by modeling tools so we can end up with an OPT with indistinguishable nodes if the modeler didn’t constraint the name on those C_OBJECTs that have the same archetype ID and path. And engineers shouldn’t trust modelers