We define the process of sorting merge input in reference to the xsl:sort process, which defines NaN to be equal to itself and empty-sequence() to be equal to itself, but preceding any other item.

This works fine for sorting, but in the text of how a merge-group is formed, we define that in terms of the 'eq' operator (section 15.7):

"Generally, two sets of merge key values are distinct if any corresponding items in the two sets of values do not compare equal under the rules for the XPath eq operator..."

But under the eq operator, NaN is not equal to itself and comparing anything to the empty-sequence yields the empty sequence. Therefore, under the current rules, one NaN is distinct from another NaN in a merge-group (and therefore wouldn't end up in the same group), but not when sorting.

This is problematic, since the current-merge-group should be equal to what is considered equal during the sorting process.

I think the intent of the text is clear (empty-sequence() is grouped together, and so is NaN), but I'd propose to add a clarification for these edge cases (or refer back to the sorting process, something like: what is equal during sorting ends up in the same bucket).