Tim, thank you for pointing out that discrepancy.  Section 3 of the Serialization 1.0 Recommendation[1] was slightly less restrictive.  It stated that the permitted values of the normalization-form serialization parameter were, "One of the enumerated values NFC, NFD, NFKC, NFKD, fully-normalized, none or an implementation-defined value."

Although an XSLT 2.0 (or XSLT 3.0) implementation would never have supplied anything but an nmtoken as the value of that serialization parameter, it's conceivable that an XQuery 1.0 implementation could support an implementation-defined value for the normalization-form parameter that was not an nmtoken.  As such, changing this to require the normalization-form parameter to be an nmtoken would be a backwards incompatibility.

However, I think it's extremely unlikely that any implementation would actually have chosen an implementation-defined value for normalization-form that didn't have the lexical form of an nmtoken, and that the risk of actually breaking an implementation is vanishingly small.  I support your proposal to introduce that restriction in Serialization 3.0.

I am speaking only on my own behalf, not on behalf of the XSLT and XQuery Working Groups.

[1] http://www.w3.org/TR/xslt-xquery-serialization/#serparam

At the joint teleconference of the XSLT and XQuery Working Groups of 26 June 2012,[2] the working groups decided to change the definition of the normalization-form serialization parameter to require the value to be an NMToken.

Tim, as you were in attendance at the call, I will assume the decision is acceptable to you, and close the bug report.

This will be implemented in the next working draft of Serialization 3.0.

[2] https://lists.w3.org/Archives/Member/w3c-xsl-query/2012Jun/0135.html