The problem with a bug like this one is that it takes us down (however slightly) the slippery slope of trying to make valid XQuery expressions out of nearly arbitrary XQueryX syntax. 

As one participant told me, "If users can write arbitrary xqueryx, and every such xqueryx needs to translate into correct xquery, i bet i could hand you dozens of other bugs...it means there are valid XQueryX documents (by the schema) that the stylesheet will turn into not-correct XQuery, but that does not mean it's broken."

Without prejudice, I'm RESOLVING this bug as WONTFIX, but am willing to hear stronger arguments either that this case is sufficiently unique to justify special treatment, or that this is one of a set of cases that are sufficiently unique (and important) to justify special treatment. 

If you accept this resolution, please mark the bug CLOSED. 

Upon further consideration, the Working Group decided that it would be worth accommodating this common case and directed me to pose a solution.  Because we believe (I think) that the only case where this is needed is when the source XQueryX (.xqx) document contains the sequence:
          <xqx:pathExpr>
            <xqx:rootExpr/>
          </xqx:pathExpr>
I propose that the solution be to modify the template for xqx:rootExpr to become:
  <xsl:template match="xqx:rootExpr">
    <xsl:if test="parent::xqx:pathExpr">
      <xsl:text>( </xsl:text>
    </xsl:if>
    <xsl:value-of select="$SLASH"/>
    <xsl:if test="parent::xqx:pathExpr">
      <xsl:text> )</xsl:text>
    </xsl:if>
  </xsl:template>

I'm leaving the bug RESOLVED, but changing the resolution to FIXED.  If you agree with this solution, please mark it CLOSED. 

Two observations about this solution:

(a) it will insert the parentheses around any root expression whose parent is a path expression, whether or not the root expression is the only child of the path expression. I don't know if this cases arises or if it matters.

(b) an arguably more elegant way of coding the solution would be:

  <xsl:template match="xqx:rootExpr">
    <xsl:value-of select="$SLASH"/>
  </xsl:template>

  <xsl:template match="xqx:pathExpr/xqx:rootExpr">
    <xsl:text>( </xsl:text>
    <xsl:value-of select="$SLASH"/>
    <xsl:text> )</xsl:text>
  </xsl:template>

Mike, I'm sold.  I've made the changes you suggested.  Thanks!

I believe that more work is needed on this. Test case Steps-leading-lone-slash-10 contains the query:

$var[/*]

The XQueryX that I generate is:

    <xqx:queryBody>
      <xqx:pathExpr>
        <xqx:stepExpr>
          <xqx:filterExpr>
            <xqx:varRef>
              <xqx:name>var</xqx:name>
            </xqx:varRef>
          </xqx:filterExpr>
          <xqx:predicates>
            <xqx:pathExpr>
              <xqx:rootExpr/>
              <xqx:stepExpr>
                <xqx:xpathAxis>child</xqx:xpathAxis>
                <xqx:Wildcard/>
              </xqx:stepExpr>
            </xqx:pathExpr>
          </xqx:predicates>
        </xqx:stepExpr>
      </xqx:pathExpr>
    </xqx:queryBody>

This transforms into a query that does not parse:

$var[( / )child::*]

Good catch!

I've updated the XQueryX stylesheet to account for the case where a rootExpr is immediately followed by a stepExpr.  In the case where it is, the rootExpr is transformed to a slash without surrounding parentheses.  Where it is not immediately followed by a stepExpr, the surrounding parens are generated. 

I've marked the bug RESOLVED/FIXED.  As you have agreed with the resolution in separate email, I'm also marking it CLOSED.