Thanks. This was good, solid information.
Yes, I was unsteady with my example xpaths. My actual code didn't use the
"//". It was simple one-level a|b|c.
The main question answered: I hoped it would not be implementation
dependent, but I was wrong.
It's good to hear that the behaviour I hoped for is in the next version.
Makes the world fit together...

Now I've got misunderstandings to work on in my code.

-tor

Michael Kay wrote:
> Firstly, //b|c and //c|b don't necessarily return the same nodes. The
> expression parses as (//b)|c, not as //(b|c).
>
> Secondly, the XPath 1.0 specification defines that a path expression
> (or a union expression) returns a node-set, that is, an unordered set
> of nodes. Some host languages, for example XSLT 1.0, specify that
> node-sets are always processed in document order. But you appear (as
> far as I can tell) to be invoking XPath from some Microsoft API, and
> I've no idea what that API says about the processing order: it's up
> to the XPath host language to define it, or it could choose to leave
> it undefined.
>
> This changes in XPath 2.0, which specifies that path expressions and
> union expressions return a sequence of distinct nodes in document
> order.