Some properties are defined as subsets of inherited properties with the {ordered} constraint, for example: RedefinableTemplateParameter::/inheritedParameter subsets TemplateSignature::parameter (see p. 196 and p. 99 of the PDF file for the UML 2.5.1 specification). The latter is {ordered}, but the subset is not defined as ordered.
In fact, the OCL implementation given for the derived property RedefinableTemplateParameter::/inheritedParameter is as follows:
inheritedParameter() : TemplateParameter [0..*]
Derivation for RedefinableTemplateSignature::/inheritedParameter
body: if extendedSignature->isEmpty() then Set{} else extendedSignature.parameter->asSet()
endif
Perhaps the inherited property does not need to be ordered? Or is it implicitly assumed that the ordering of the superset would carry over to the subset?
You probe too far into the dark corners. You must remember that the UML specification is a best endeavors comprise by a well-intentioned committee with limited tool support.
Amongst other things UML allows you to draw pretty pictures of model-oriented C++ or Java systems. Since invocation of super is a programmer discretion, observance of the Liskov Substitution Principle is a design choice and so UML must support that choice. (A clean modelling language would not have private/protected/public which are ignored by OCL at analysis time. Rather they should be code generator markups.)
LSP would dictate that subsetting an ordered/unique feature must yield a correspondingly ordered/unique derived feature since invoking the super-accessor should return the super typing. But in a non-LSP world the super-accessor may not exist or maybe the implementor just wants to prohibit users exploiting ordered/unique or has strange multiple-inheritance aspects.
The situation gets much worse with redefines where things really can change incompatibly. The original intention of redefines seems to have been to manually 'implement' an overloading algorithm for the UML metamodel. However for user models, UML specifies that OCL specifies overloading and correspondingly, OCL specifies that UML specifies overloading. Nonetheless the flexibility of redefines allows modellers to create completely unintelligible/unimplementable designs.
For your specific example the spelling of parameter rather than the more consistent ownedParameters may have confused the author into thinking there is just one and so ordered is irrelevant.