> So that would fall under XPath "shortcut" expressions and tricks!
> Specification could be:
> If type of predicate is number
> | then imply position() = that number (which is a test and 
> thus gives a
> true/false result)
> | else cast expression to boolean

Not quite. You're getting the effective boolean value of the expression,
which is not quite the same as casting to a boolean. For example, given the
string "false", casting to boolean gives false(), but the EBV is true().
> 
> I find it a very "dangerous" shortcut if you do [something] 
> relying on the type of  'something'
> to imply position()= if it is what you meant.

Yes, polymorphic operators always carry this kind of risk: it's the same as
Java which overloads "+" to mean addition and string concatenation. Are you
sure you know what ''+32 is?

By all means use [position()=x] or [number(x)] if you want to make yourself
clear. In 2.0, I think a better approach is to be rigorous about declaring
the types of variables and parameters, so that such mistakes will not occur.
I'm afriad people who write ['2'] just need to learn not to, as indeed do
people who write

<xsl:variable name="x">2</xsl:variable>

Michael Kay
http://www.saxonica.com/