Currently xsl:merge-key is defined mostly in terms of xsl:sort and refers to that section, specifically, section 15.5 says:

"The syntax and semantics of an xsl:merge-key element are closely based on the rules for the xsl:sort element (the only exception being the absence of the stable attribute)"

However, xsl:sort defines the absence of both the sequence constructor and the select attribute to be treated as select=".". In contrast, the text on xsl:merge-key says:

"[...] the result of the expression in the select attribute of the Nth xsl:merge-key child of the corresponding xsl:merge-source element, or in the absence of the select attribute, the result of the contained sequence constructor."

Further paragraphs don't specify this, which means that an empty xsl:merge-key returns the empty-sequence(), and not the context item.

This leads to two possible ways of interpretation of the text:

(1) Merge by the rules of xsl:sort, meaning the context item is selected
(2) Merge using the empty-sequence(), which results in declaration-order sorting (by virtue of the stability conflict resolution rules)

I think the second option is not what was intended as it seems a very uncommon use case. But it is easy to go either way with the current rules.

Since it is not uncommon for instructions to have a default for the absence of the select attribute and users are accustomed to that behavior, I think we should fix this omission by choosing option (1) above in an erratum.

I have not researched (yet) how it is presently implemented in existing processors.