Re: A beef with XSLT Sometimes too complicated

 <xsl:variable name="x" 
    select="if $var then select(@id='1') else select (@id='2')"/>
  <something id="1">
     hello!
  </something>
  <otherthing>
     goodbye
  </otherthing>


actually I can't guess what the intended semantics of that are.
I can guess you mean to define $x to be one of those elements, but where
would control flow after the xsl:variable? On the face of it it would
produce both the elements in teh result as they are literal result
elements.

In XSLT2 you can more or less arbitrarily mix xslt and xpath code by way
of xslt functions.

<xsl:function name="x:f">
 <xsl:param name="here"/>
 <xsl:apply-templates select="$here/a"/>
</xsl:function>

<xsl:function name="x:g">
 <xsl:param name="here"/>
 <xsl:apply-templates select="$here/b"/>
</xsl:function>

<xsl:value of select="if (foo) then x:f(.) else x:g(.)"/>

obviously the functions can be any xslt construct, template calls,
for-each instructions, whatever.

This is basically how xq2xml works. As Mike just mentioned XQuery is
more naturally compositional than XSLT, you can nest expressions much
more freely, so when converting to XSLT, xq2xml is either in xslt mode
or xpath mode. If its in xslt mode and needs to generate some xpath, it
generates a select=..." attribute and then switches to xpath mode.
Conversely if its in xpath mode and needs to generate some xslt (to
generate element nodes, or execute xsl:for-each, usually) then it puts
all the generated xslt in a function body, and puts the function call in
the xpath expression.

David