UML22 — 11.3.47 on StructuralFeatureAction (and related sections on subclasses)

Consider a link object that is an instance of an association
> class that owns its ends. In this case, according to the
> metamodel, it is the association class that is the
> featuring classifier of the end properties (owningAssociation
> subsets featuringClassifier). The properties of the object
> input pin of a StructuralFeatureAction are determined by the
> featuring classifier of the feature, which would imply that
> the object being accessed in the case of an owned feature of
> an association class is the link object that is the instance
> of that association class.
>
> BUT, the semantics of StructuralFeatureAction say that "If
> the structural feature is an association end, then actions on
> the feature have the same semantics as actions on the links
> that have the feature as an end. See specializations of
> StructuralFeatureAction" – which is consistent with your
> claims. This is an inconsistency in the spec. For the
> semantics to work correctly, the syntactic constraints (on
> typing of the object, visibility,
> etc.) would have to be adjusted for the case of an
> association end owned by an association class.

(Note that the StructuralFeatureAction subclause is numbered 11.3.48 in Version 2.2.)
The issue summary states that "the properties of the object input pin of a StructuralFeatureAction are determined by the featuring classifier of the feature." However, the specification does not actually formally require this. Rather, Subclause 11.3.48 includes instead the following constraint:
[2] The type of the object input pin is the same as the classifier of the object passed on this pin.
This statement is actually tautological if the normal typing rules are enforced, and does not place any constraint on the relationship of the type of the object input pin and the featuring classifier of the feature.
The intent really is that a StructuralFeatureAction for a structural feature that is an association end have the same semantics as for the appropriate link action. The ownership of the association end should not matter. For example, this allows a ReadStructuralFeatureAction to be used to read the navigable opposite end of a binary association, whether that end is owned by the opposite end type or owned by the association itself (in which case the ReadStructuralFeatureAction acts like a ReadLinkAction). This way, the action does not have to be changed just because the model may be updated to change the end ownership - the ability to read the end depends only on its navigability.
If this is clarified and formalized in the specification, then the above issue becomes moot.