The original XQuery version of the query is:
    <elem><![CDATA[]]>{attribute name {"content"}}<alem/>
    </elem>

I believe the XQueryX version of the query is equivalent.
That is, the xqueryx.xsl stylesheet translates it back to:
    <elem> { text {"" } } { attribute name {"content" } }<alem></alem></elem>
which has the same behaviour as the original query.


It's true that the underlying semantics are slightly different. With respect to section 3.7.1.3 (XQuery 1.0) or section 3.8.1.3 (XQuery 3.0),
    <![CDATA[]>
supplies no 'literal characters', and therefore does not contribute a text node to the content sequence [points 1b and 1c], whereas
    { text {"" } }
does contribute a text node to the content sequence [point 1e], which is then removed [point 3: "any text node whose content is a zero-length string is deleted from the content sequence"].

But either way, the outcome is the same: by the time we get to point 4, there is no text node before the attribute node in the content sequence, so err:XQTY0024 is not raised. That's basically the point of the test.

You are right, it's our bug.
Thank you.

Oh, by the way: if your implementation supports Static Type Analysis as defined in the Formal Semantics, then it *would* raise err:XQTY0024 (basically because the analysis isn't smart enough to know that the text node will be removed). But it would do so for both the original and round-tripped queries, so the XQuery and XQueryX versions are still equivalent.