UML22 — Datatypes in UML profiles

The UML Superstructure section on profiling (18, 18.3) is vague about the datatype usage in profiles.
In particular, it is not clear what (if any) datatypes can the user define and use in his profile as types of the tags.

--------------------------------------------------------------------------------
Datatypes used in profiles (e.g. as types of the tags) are not ordinary UML datatypes, but MOF datatypes (if I am not mistaken).
Hence it is not obvious if all of the various datatype possibilities, defined in CMOF, can be used by a profile creator.

It would be nice to have some clarifying statement in the Semantics section of the 18.3.6 Profile paragraph
In the same manner as the possible associations between stereotypes is clarified there (page 663, at the bottom):

Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is
owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by
the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than
the other class/metaclass
(a little side note - I am not sure if this passage is correct - ?metalevel mixing? but this is irrelevant for the issue I am describing)

--------------------------------------------------------------------------------
I can think of the 4 distinct cases of datatypes that the modeler might use in his profile:

#1 Enumerations
#2 New primitive types, narrowing the existing primitive types - String, Integer, Boolean, UnlimitedNatural.
e.g.

#3 Completely new primitive types, e.g. Double
#4 Complex datatypes, defined by the user, composed of fields of primitive types and other complex types.
e.g.

#1 and #2 are the least problematic. #1 is widely supported even in the current crop of modeling tools and
#2 is conceptually simple (handling is the same as existing primitive types + additional constraints)

What I am worried about is #3 and #4.
#3 is problematic; the question arises about how the values of this type are then handled in the model and how they are
serialized into the XMI.
Maybe we could state here that if the tool allows the user to define his own primitive types, then the user is responsible for
extending the tool (through some kind of plugin mechanism) - providing at least the rules of how to serialize such datatypes into the string,
to be written into the XMI.

#4 Is theoretically non problematic (supposedly, it is described how to serialize such complex datatype values - XMI 2.1.2 spec, 07-12-01.pdf, 4.8.7 paragraph).
However I haven't seen live implementations of this. Is the usage of such datatypes in the profile legal?

--------------------------------------------------------------------------------
So, to summarize, we should clarify here, if all of these cases must be supported by the UML tool. Are there any
semantic variation points or compliance levels here?

No Data Available