Technically XPath 1.0 returns node-sets rather than node sequences. In the XPath 1.0 specification there is no statement about the order of these node-sets - indeed, being sets, they have no intrinsic order.

However, XSLT 1.0 always processes the node-sets returned by XPath 1.0 in document order, and because of that precedent, there is a widespread expectation that XPath results will be in document order when XPath is invoked from languages other than XSLT. However, there is nothing in the spec to guarantee this. In XPath 2.0 the user expectation becomes part of the spec, and the results of a path expression MUST be in document order.


I could find the following bug-report which looks like the issue: Bug 363252 - proximity position in libxml2's xmlXPathEvalExpression() reported 18 Oct 2006 and confirmed dating back since May 2006 which is before the 2.6.26 version in question.

This should have been fixed in libxml2 2.6.27.


It looks like an bug in 20626 version:

It process first all child text nodes in document order, then content of child element nodes. Should be as result on your machine