I believe there is a typo/bug on https://www.omg.org/spec/UML/2.2.
In the "Informative Machine Consumable Documents" section, The Filename for ptc/08-05-12 is "Infrastructure" and the Filename for ptc/08-05-06 is "Superstructure" and it should be vice versa.

When modelling a constraint in UML on several constrained elements, how is itpossible to know which constrained element is the context of the constraint?

In the spec, the metaattribute context of Constraint is derived, but the spec does not define how it is derived.

The spec states: "An entry point pseudostate is an entry point of a state machine or composite state. In each region of the state machine or composite state it has a single transition to a vertex within the same region." This is slightly ambiguous as one could take it to mean that the region is the region who owns the target dirctly. This would allow one to create the case where we can create an invalid active state configuration. consider: S1's region1 owns S2 and S3 who both have sub verticies. An entry point on S1 should only be able to target one vertex with region1 (either a direct or deeply nested vertex), but not more then one. If the assumption by a user was made that both the verticies in S2 and S3 could be targeted (since they are owned by different regions) then the tooling would essentially be allowing concurrent entries into a single region. Where as, really we need to specify more along the lines of that the LCA region of the source and target may have at most a single transition. An entry point pseudostate is an entry point of a state machine or state. For each transition that targets a vertex in region R, there may not exist another transition targeting a vertex in region R nor any region contained within R. Also, given the alternate semantics of entering a state (that regions don't have to be entered and the state itself can remain active), entry points should not be required on composite states only. Connecting to an entry point with no outgoing transitions or to the state border itself should be considered semantically the same. One usecase for this is that users may define entry/exit code on the state itself to preform some basic behavior, but in redefined contexts want to enhance the behavior by continuing that transition to a sub vertex.

Concrete specialization of the Relationship meta-class are missing. Except few cases restricted to very specific usages (import/merge, association), and according to the current meta-model, all concrete instaciations of Relationship are Dependencies. This situation has an undesirable side-effect in UML models but also in some UML profiles like SysML and MARTE. Indeed, specialized or extended relationships like Deployment or Allocation generate unexpected dependencies between related elements. A solution might be to add a concrete (Directed)Relationship meta-class in the meta-model. The concept of "Allocation" is very generic and might provides that meta-class. It would be a convenient generalization for Deployment.

I propose to define the Comment as a NamedElement instead of Element. The SysML and UPDM working groups identified that it is necessary that comment based model elements have a name, could be packaged and identified.

Package merge is missing a rule for when two elements have conflicting values for isLeaf, cf. the rule for abstract elements

The semantics of associating a use case with another use case, or indeed anything other than an actor, are unclear. There is a rule specifying that use cases may be only be associated with other use cases with different subjects because they describe a complete usage of the subject. But that doesn't explain what it means to have any association. The only hint is in the notation section that gives some examples as "(e.g., to denote input/output, events, and behaviors)." However these details ought to be part of semantics and expanded on.

A common task is to implement the operations of an interface I in a class A. The implementation of an operation has a specification reference to the realized operation. In the current UML specification, the operation must be copied into the class before it can be realized, since only owned behavioral features can be referenced: "(section 13.3.2) ... The behavioral feature must be owned by the classifier that owns the behavior or be inherited by it.". I.e. the standard only allows to reference inherited operations, but not realized operations. This is not very practical, since it implies not only copying the operation but also assuring that it remains synchronized with the operation that is defined in the interface (of course, the modeling tool could do the synchronization, but it would still imply storing redundant information within the model). It would be good to authorize a reference to an operation in a realized interface.

The reader may be led to believe that the application of the stereotype <<clock>> changed the model by adding an operation "Click" to the class StopWatch. It should be clarified that the operation must be owned by the StopWatch even without applying the stereotype. The stereotype instance may, of course, be associated to this operation, and serves as a pointer, for example, to be used in model transformations. Figure 18.18 does not provide this information; it shows the result of the application and not the state before.

The example in Figure 18.11 is badly designed in multiple ways and is strongly misleading. Although it serves to explain the package import, it should not suggest an improper application of stereotypes. The stereotype defined here (Device) holds attributes which are not typical for devices as such. For instance, a device is not expected to have a color or volume. It may make sense to apply this stereotype to a class of TVs, but not to a class of dishwashers, for example. A better disctinction would be electrical versus non-electrical devices, or handheld versus non-handheld. Second, the attributes as shown here refer to properties which are significant for instances, not for classes. The example basically shows that we can create a TV class, declaring this to be a device. The Factory package shows an instantiation, setting the volume to some value, but omitting the remaining attributes - which must be set as well. The volume parameter for a class of TVs is questionable - what should it mean? This may lead the reader to believe that the volume parameter is meaningful for instances of the model element, although it is associated to the stereotype instance which is associated to the model element. Basically, the element in the Factory package denotes the class of all TVs whose volume is set to 10. This still does not imply a meaning for the instances.

Figure 18.9 shows a presentation option for an Interface which has not been introduced before (circle within box)

Figure 18.8 includes a Metamodel formalism which has never been introduced, in particular with respect to customized metamodels. The presentation as a package with a triangle is new at this point. Although the concept of a metamodel is verbally explained in the Infrastructure, there is no abstract syntax. It becomes implicitly clear that a metamodel is a package. I suggest to insert a definition of a Metamodel as a subclass of Package in the Infrastructure document or in the Profiles chapter of this document. This also allows to explain what is meant by "applying a metamodel". Also, the term "a UML2 metamodel" (p. 666) is unclear, taking into account that UML2 itself is a metamodel. This all should be clarified due to the importance of the metamodel concept in this chapter. The same applies to the respective chapter of the Infrastructure document.

Should there be a constraint for extends equivalent to 16.3.6 [4], that extends should be an acylic relationship between use cases?

The UML specification text for PrimitiveType states that it has no operationsnor attributes:

"A primitive type defines a predefined data type, without any relevant substructure (i.e., it has no parts in the context of
UML). A primitive datatype may have an algebra and operations defined outside of UML, for example, mathematically."

However, because PrimitiveType is a subtype of DataType in the spec, it inherits the ability have attributes and operations.

Constraints need to be added to restrict this, or else PrimitiveType should not specialize DataType.

The current situation is confusing to tool vendors. Potentially any imported XMI might have a PrimitiveType with attributes and operations defined according to the specification.

It is not clear whether it is allowed to have a generalization relationship between two model elements that have different stereotypes. Please clarify in the uml specification