I'd still be interested to know if (a) there is more to LibXSLT's
 non-conformance

What I posted in a parallel thread
http://www.biglist.com/cgi-bin/wilma/wilma_hiliter/xsl-list@xxxxxxxxxxxxxxxxxxxxxx/200804/msg00515.html?line=8#hilite
may well turn out to be such a non-conformance.

With the context node having the string value of a QName, like
"xsl:number", xsltproc fails on "element-available(.)":

    runtime error: file staudinger.xsl line 56 element value-of
    element-available() : invalid arg expecting a string
    runtime error: file staudinger.xsl line 56 element value-of
    XPath evaluation returned no result.

For xsltproc, you have to explicitly extract the string value by coding
"element-available(string(.))".

    Function: boolean element-available(string)
    The argument must evaluate to a string that is a QName.