Consider this stylesheet

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
  <xsl:key name="mykey" match="pz" use="number()" version="1.0"/>
  <xsl:key name="mykey" match="nz" use="number()"/>

  <xsl:template match="/">
    <out><xsl:copy-of select="key('mykey',0)"/></out>
  </xsl:template>
</xsl:stylesheet>

applied to this input

<doc><pz>0</pz><nz>-0.0</nz></doc>

According to section 16.3.2 of XSLT 2.0[1] "if any of the xsl:key elements in the definition of the key enables backwards compatible behavior, then the value of the key specifier and the value of the second argument of the key function are both converted after atomization to a sequence of strings, by applying a cast to each item in the sequence, before performing the comparison."

It's unclear to me from that description whether the conversions to sequences of strings occurs only for the values of the key specifiers of those xsl:key elements that enable backwards compatible behaviour and comparison with those specifiers, or for the key specifiers of all the xsl:key elements for that key, if at least one enables backwards compatible behaviour.

If the former was intended, the value of the key specifier for pz and nz would be cast to sequences of string - '0' for pz and '-0' for nz - the second argument of key would be cast to the string '0'.  Only the key specifier for pz would match, and the result of the above stylesheet would be

<?xml version="1.0"?><out><pz>0</pz></out>

If the latter reading was intended, the value of the key specifier for pz would be cast to the string '0' as would the value of the second argument in comparing with that key specifier, so pz would be selected.  The value of the key specifier for nz - the xs:double value -0.0 - would be compared to the value of the second argument - the xs:integer value 0 - and so nz would also be selected.  The result would be

<?xml version="1.0"?><out><pz>0</pz><nz>-0</nz></out>

If it helps, the description of the backwards compatible behaviour first appeared in the working draft of 11 February 2005.[2]  I couldn't find any discussion in the mail archives of this particular aspect of backwards compatibility after a brief search.

[1] http://www.w3.org/TR/xslt20/#keys
[2] http://www.w3.org/TR/2005/WD-xslt20-20050211