SYSML2_ — Message Connector Ends are Absent by Default; If Ends are Specified, Message is Indistinguishable from Flow

Current spec mandates that messages are implemented as flow connectors without ends.
>> (8.4.9.6, page 389, "A message declaration of the form ....
>> is parsed as an abstract FlowConnectionUsage, but without any connectionEnds (see 8.2.2.13.4 ),")

Instead, the connectivity information (what this connector is attached to) is implemented as
sourceEvent and targetEvent parameters that need to be redefined.

This is problematic from implementation standpoint as now we need two different codes for drawing/displaying conectors -
one for all connectors except messages and another one for messages.

There seems to be no strong reason why it should be so. Even the very abstract, non-structural,
purely-behavioral connectors, such as Successions do have ends.
It would be better to make message connectors as connectors with ends, as all other connectors.

The only reason to implement them this way seems to be - to make messages "more" distinguishable from flows.
As there is no special metaclass for messages, the same FlowConnectionUsage is reused.
So flow connection with no ends => message, flow connection with ends =>flow seems to be distinguishing criterion.

Now, if user creates connector ends explicitly/forcefully (using the extended syntax of {<connectorbodydetails>}),
the message connection ceases to be distinguishable from flow connection.
But this is a problem, since users do want to specify message connection ends - namely to indicate the sending and receiving parts.

The spec vaguely says (in chapter 7.13.6) that messages should be abstract, while flows (supposedly) should not be so.
The reasoning for no ends for messages seems to be that connectors without bound ends are abstract connectors (there is such a rule elsewhere in the spec),
thus guarranteeing that connector is abstract; but that is a resoning in the opposite direction
(binding of connector ends should not/does not prevent the connector from being abstract).

A better rule to distinguish messages and flows perhaps could be devised.
Heavyweight approach would be to have a dedicated metaclass for messages, but we understand that this would be a signifficant spec change.
Criterion of inheritance from appropriate library class seems to be sufficient?

To summarise:

a) we propose that messages could also have normal connector ends bound to parts.
Perhaps this could be analogous to the arrangement that flow connectors currently have:
when specifying flow connector as being from a.b.c to d.e.f,
the connector ends are filled as a.b and d.e, while the last steps in the chain - c and f go into special flow-specific features.
In the same manner when message is specified as being from a.b.c to d.e.f, the connector ends could be filled as
as a.b and d.e, while the last steps in the chain - c and f (EventOccurrences) go into message-specific features .

b) The rule to distinguish messages and flows should be revised.