The content model for xsl:merge-input is

<xsl:merge-input
  select? = expression >
  <!-- Content: (sequence-constructor, xsl:merge-key+) -->
</xsl:merge-input>

This makes it legal to write

<xsl:merge-input>
  <xsl:variable name="o">ascending</xsl:variable>
  <xsl:sequence select="abcd"/>
  <xsl:merge-key select="." order="{$o}"/>
</xsl:merge-input>

But this is meaningless: the criteria for sorting/merging cannot depend in this way on the data to be sorted. It's legal because of an accident of the rules for variable scope: rather than saying that the scope of a variable is the rest of the sequence constructor, we say that it is all following sibling elements of the xsl:variable.

Proposed solution: in 9.7, after the following:

<quote>
A local variable binding element is visible for all following siblings and their descendants, with the following exceptions:

1. It is not visible in any region where it is shadowed by another variable binding.

2. It is not visible within the subtree rooted at an xsl:fallback instruction that is a sibling of the variable binding element.

3. It is not visible within the subtree rooted at an xsl:catch instruction that is a sibling of the variable binding element.
</quote>

add a fourth exception:

4. It is not visible within the subtree rooted at an xsl:merge-key instruction that is a sibling of the variable binding element.