I thought I had already responded to this.
Saxon isn't fully implementing the specification for keys of a type other than string.
Your query did lead me to discover that XPath has made a change in the definition of the eq operator which potentially affects the definition of keys (untyped atomic values used as operands to "eq" are now always treated as strings), and we may therefore consider change the definition of keys to use the "=" operator rather than "eq".
Michael Kay

From: saxon-help-admin@lists.sourceforge.net [mailto:saxon-help-admin@lists.sourceforge.net] On Behalf Of Alexander Shrago
Sent: 11 May 2004 13:44
To: saxon-help@lists.sourceforge.net
Cc: Alexander Makanin
Subject: [saxon] question

Hello Mr. Kay!
Please suggest  how to explain the result of my test with saxon 7 :

According to XSL Transformations (XSLT) Version 2.0 (W3C Working Draft 12 November 2003):

"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
call key('k', '2') return the same result as call key('k', 2), not empty sequence!

Best regards!