Since revision 62270539, entitled 'Optimizing '//' in XPath expressions,' the XPath evaluator has been incorrectly handling some XPath expressions such that // binds stronger than []. Consider the following expression:

    //a[1]

In expanded syntax, this is:

    /descendant-or-self::node()/a[1]

After revision 62270539, it becomes:

    /descendant::a[1]

Which is (incorrectly) equivalent to:

    (/descendant-or-self::node()/a)[1]

Which will return the first a node in the document, whereas //a[1] will return every a node that is the first child of their respective container.

The XPath 1.0 specification actually covers this:

    NOTE: The location path //para[1] does not mean the same as the location
    path /descendant::para[1]. The latter selects the first descendant para 
    element; the former selects all descendant para elements that are the first 
    para children of their parents.

I have not thought out a fool-proof solution, but I'm guessing the correct way to handle this is to disable the optimization if there are predicates attached to the location step.