KERML_ — checkFeatureParameterRedefinition fails for named-argument invocations

In 8.3.3.3.3 Feature, the constraint checkFeatureParameterRedefinition requires:

If a Feature is a parameter of an owningType that is a Behavior or Step, other than the result parameter (if any), then, for each direct supertype of its owningType that is also a Behavior or Step, it must redefine the parameter at the same position, if any.

However, in the textual BNF in 8.2.5.8.3 Base Expressions, a NamedArgumentList for an InvocationExpression is parsed with parameter redefinitions in the order of the argument list, not the original parameter list. Indeed, according to the description in 7.4.9.4 Base Expressions, named arguments may be "given in any order". But, if they are given in an order different than the original parameter order, this will violate checkFeatureParameterRedefinition. And then adding implied redefinitions to the InvocationExpression parameters, in the original parameter order, would potentially result each of the InvocationExpression parameters incorrectly redefining two different of the original parameters.

Exclude InvocationExpressions from the constraint

InvocationExpression is the only case in which the named-argument notation can be used and the checkFeatureParameterRedefinition constraint currently applies. But reordering parameters is actually safe in this case, because an InvocationExpression is to have a single function as its type, and an InvocationExpression cannot be the direct target of another InvocationExpression. So, the simplest solution to this issue is simply to exclude InvocationExpressions from the checkFeatureParameterRedefinition constraint. Allowing greater freedom for reordering parameters can be considered in other cases in the future, as a functionality extension, after more consideration.