Incorrect handling of mixed backward-compatibility xsl:key
When operating in cases where two or more keys with the same name differ in backwards-compatibility, the implementation currently merges into the appropriate index (in document order) all matched nodes, regardless of source.
In 2.0+ keys are atomic, in 1.0 keys are strings. This means not only that the correct type for the given key backwards state should be used in forming the index entry keys, but also as the get key to extract nodes that were collected by the appropriate key declaration .
To correct this, separate indexes for 1.0 and 2.0 keys are collected and held as a pair against the key name. In cases of uniform compatibility the entry in the corresponding index are returned. With mixed compatibility entries from both indicies are combined with a node union (i.e. in document order and deduplicated)
Please register to edit this issue