Thanks for reporting this. The Saxon implementation is not
quite up-to-date with the latest spec in this area, and I will make sure the
documentation is updated to reflect this.
In fact, your note has prompted the observation that the
definition of the "eq" operator in XPath has changed since this text in the XSLT
specification was written, and we (the WG) need to review whether it still has
the effect that was intended, especially as regards the handling of
untypedAtomic key values. For example, the current spec implies that if the key
says use=@code and the document is untyped, then
the call key('k', 1234) will never match anything, which is a bigger
incompatibility from 1.0 than was intended or documented.
according XSL Transformations (XSLT) Version 2.0 (W3C Working Draft 12
"An XSLT 1.0 processor compared the value of the
expression in the use attribute of xsl:key to the value supplied in the second
argument of the key function by converting both to strings. An XSLT 2.0
processor compares the values as supplied. In the most common case, where the
values of the keys are untyped atomic nodes, this will give the same results.
In cases where the key value is a more specific type (for example xs:string or
xs:integer) a match will be obtained only if the value supplied to the key
function is of a comparable type. For example if use="string-length(@x)" is
specified, then the function call key('k', 2) will give the same results in
XSLT 2.0 as with XSLT 1.0, but the call key('k', '2') will always return an
empty sequence with XSLT 2.0."
We test this sample, but
key('k', '2') return the same result as call key('k', 2), not empty sequence