request to enhance singleInstance for the case of different namespaces

[ghost]

The specification V3.4 describes the annotation singleInstance in section 18.5. The described behavior is rather a onceUseOfClass and is only defined if the class and its instance are in the same namespace.
The remaining amount that the class and its instance are in different namespaces is omitted. However, this variant, in the sense of singleInstance without deleting the class, is also quite interesting.
As an example you can take the model World described in the specification V 3.4 under section 18.7 (page 244). Additionally it is assumed here that it is part of a package and has no relation to state machines.
In the example, the model is instantiated with a fixed name and as inner. A second instance makes little sense for the case of a class World. With singleInstance=true you could really prevent the second instantiation. When deleting the instance, the class should be preserved. In other words, for different namespaces, singleInstance=true means that the class can only be instantiated once and World can be instantiated again after deletion of the instance.

[HansOlsson]

I totally agree that it doesn't make sense to have multiple copies of a model such as "World" that is intended to be used with inner/outer (and we already have annotations to indicate that it should be inner/outer).

However, I don't see why we would need a new variant of the singleUse-annotation for this use case. In practice the two differ so much that I think it should be a different annotation.

We already have defaultComponentPrefixes in "18.7 Annotations for the Graphical User Interface" adding inner/outer - and it doesn't make sense to add inner/outer to a component declaration with a different name. Therefore I think we don't have to add any new annotation-variant, but just indicate that a inner/outer only makes sense if the default component name can be used.
That also seems to indicate more specific error messages.

If there any similar use-cases without inner/outer we will have to investigate that separately.

[HansOlsson]

Proposal: For defaultComponentPrefixes add (may even be non-normative):

If the prefixes contain inner or outer and the default name cannot be used (e.g., since it is already in use) it is recommended to give a diagnostic.

[HansOlsson]

Agreement by acclamation to add as non-normative text