This may well be a well-known problem, tho a search of the archive did not turn up anything very like it.  Mr Pawson's site yielded a hint from Michael Kay that "Yeah, ya get that."  I have just started to use saxon on a new XP machine.
 
I have some XML as follows - note the extra blanks in 'G  4' and 'G  6'.
 
<album medium="CD" label="Seon" ident="SB2K 63190">
<performers artist="Kuijken et al"/>
<entry>
<composer>Boccherini</composer>
<work>Sonata, Cello</work>
<detail key="C" catalog="G  6"/>
</entry>
<entry>
<composer>Boccherini</composer>
<work>Sonata, Cello</work>
<detail key="A" catalog="G  4"/>
</entry>
<entry>
<composer>Boccherini</composer>
<work>Sonata, Cello</work>
<detail key="C" catalog="G 17"/>
</entry>
</album>
 
and some XSL that goes like this:-
 
<xsl:for-each select=
    "//entry[generate-id(.)=generate-id(key('composernames', substring(composer,1,3))[1])]">
  <xsl:sort select="composer"/>
  <xsl:for-each select="key('composernames', substring(composer,1,3))">
    <xsl:sort data-type="text" order="ascending" select="composer"/>
    <xsl:sort data-type="text" order="ascending" select="detail/@catalog"/>
    <xsl:sort data-type="text" order="ascending" select="work"/>
    <xsl:sort data-type="number" order="ascending" select="detail/@number"/>
    <xsl:sort data-type="text" order="ascending" select="detail/@opus"/>
    <!-- process into an HTML table -->
  </xsl:for-each>
</xsl:for-each>
<xsl:value-of select="$nl"/>
 
The end result is that G17 sorts before G4 before G6 - as if the comparison disregards extra blanks.  About 18 months ago, I raised the identical question on the xalan list, as bug 13508.  And started to use saxon 6.5.3 (Windows saxon.exe) instead, because at that time saxon did what I wanted!  One commentator stated then that xalan did this (and saxon did not) because of the way Java CollationKeys treat whitespace.  Well, now saxon does the same...  I ran up some Java that goes (thank you, Java Doc!):-
 
 Collator myCollator = Collator.getInstance();
 CollationKey[] keys = new CollationKey[5];
 keys[0] = myCollator.getCollationKey("G 17");
 keys[1] = myCollator.getCollationKey("G  4");
 keys[2] = myCollator.getCollationKey("G  6");
 keys[3] = myCollator.getCollationKey("G 4");
 keys[4] = myCollator.getCollationKey("G 6");
 System.out.println( keys[0].compareTo( keys[1] ) );
 System.out.println( keys[0].compareTo( keys[2] ) );
 System.out.println( keys[1].compareTo( keys[2] ) );
 System.out.println( keys[1].compareTo( keys[3] ) );
 System.out.println( keys[2].compareTo( keys[4] ) );
 
And sure enough, the answers are -1, -1, -1, +1 and +1.  FWIW, I assume 'G  4' is nominally greater than 'G 4' because it's longer.  Can this be fixed, or is it working as designed?