BPMN21 — All None Start Events should get a token at instantiation, if the Top-level Process or Global Process (or even Sub-Process) contains multiple Non Start Events

Section 10.5.2 on page 238 states:

If the Process is used as a global Process (a callable Process that can be invoked from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered. The targetRef attribute of a Sequence Flow incoming to the Call Activity object can be extended to identify the appropriate Start Event.

1. Bug: the text only mentions "Global" processes and not "Top-level" processes, which is another but similar category of processes (p. 239). I find no semantic definition about multiple None Start Events in Top-level processes. I think, it should be the same semantic as for Global processes.

2. Bug:

As already mentioned in Bug report BPMN21-413 (https://issues.omg.org/issues/BPMN21-413) there is a semantic inconsistency with the definition of the process instantiation (also Section 10.5.2 on page 238):

All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated.

To bring both text passages together, I assume the term "Flow Objects" refers more likely to "Activities", because multiple start events are usually handled in an exclusive manner (defined at multiple places in the specification).
*But, in my mind there is no semantic difference between an Activity A with no incoming sequence flow and Activity A connected to a None Start Event.* (This just seems to be a modelling preference.)
So, the question is, how to handle multiple None Start Events in a Global and Top-level process? Exclusive (like the other typed start events) or Inclusive (like Activities without an incoming sequence flow) semantics?

Solution:

To stay consistent (no semantic difference between an Activity with or without a None Start Event), I plead for the inclusive semantic, i.e. to put a token into every None Start Event if the process was instantiated via a None Start Event.
If the process is instantiated via a typed start event, the exclusive semantic should remain.

Additionally, this is more user-friendly from a modeling perspective than the alternative: if Start Events have to be used (maybe because of a modeling guideline), the parallel semantic would require to have one None Start Event connected to a Parallel Gateway connected to all parallel-executable Activities. This could look very messy compared to one None Start Event at each Activity.

The disadvantage is the difficulty to model/implement the exclusive start if it is needed. In my experience I have rarely seen it and the inclusive start is way more often required for multiple None Start Events.
But let's look into that: For a Global (callable) process you can still use the existing targetRef attribute on the incoming sequence flow to refer to/instantiate just one None Start Event.
None Start Events are also typically used for a manual process start in a process automation engine. If it is really intended to just put a token into one specific None Start Event, you could alternatively 1. use a Message Start Event or 2. the process engine can offer a way to just start a specific None Start Event.

3. Related Improvement:

If the semantic will be defined as suggested in Bug 2 for multiple None Start Events, it is also possible and useful to allow multiple None Start Events in embedded Sub-Processes. The entry into the Sub-Process would put a token into every existing None Start Event.