OCL23 — OCL 2.1 11.2.3 Navigated Implicit Conversion to Collection Literal

The Issue 14981 considered use of explicit null as a Collection.

11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

Surely when the null arises as a navigation result, the isOrdered and isUnique characteristics of the navigated property should determine what CollectionKind the null result is converted to?

However meta-modelling tools and meta-modellers pay little attention to the isUnique and isOrdered characteristics of zero and unit multiplicity properties. Using this overlooked information may cause surprises.

7.6.3 Navigation over Associations with Multiplicity Zero or One suggests non-collection are converted to Sets. Similarly 7.6.5, 9.7. So there is a contradiction in the normative conversion to Set or Bag. Set seems more sensible and what the non-normative clauses suggest.
Using the accidental ordered/unique attributes of non-collections would lead to horrible surprises for existing usage, so it must be conversion to a set.
Since the conversion of null yields an empty set, whereas any other object yields a single element set, the Set size is data dependent and so must be determined at run-time and cannot be expressed as a CollectionLiteralExp. Rather, evaluation of PropertyCallExp and OperationCallExp must detect a mismatch between a non-collection source type and a collection-type referredOperation class.
Delayed resolution is inconsistent with OCL's static typing, so let us make it explicit by defining OclAny::oclAsSet() for the static analysis to invoke and perform the conversion. The conversion is represented as a regular OperationCallExp in the AST and only type-dependent run-time decisions need to be made.
Note that the revisions below do not address the deficiencies in the normative Clause 9 text raised by Issue 15790. We continue to rely on the final sentence of 9.7: "The mapping is not formally defined in this document but should be obvious."