Saxon

The basic problem is a failure to handle a path expression (or for-each expression) whose LHS is a let expression:

(let $x := data($y) return a / b[$x = @y]) / c

This expression is constructed as the result of a previous optimisation.

The simplest (though ad-hoc) aproach might be to move the variable binding out of the path expression, making it

let $x := data($y) return ( a / b[$x = @y] / c )

I changed LetExpressionAdjunct to be a TransmissionFilter and it fixed this case. Unfortunately it broke other tests, notably tests where the "select" rather than the "action" part of the LetExpression is consuming. I don't immediately see a way around this apart from having two different versions of LetExpressionAdjunct for the two cases, which is unconventional, but might be doable.

I've changed it to use a different StreamingAdjunct depending on which subexpression is consuming, and this both fixes the bug and solves the regression problems. I'm not very happy with this design (partly because we need a StreamingAdjunct in order to decide which subexpession is consuming...) but it will do for a patch. For 9.7 we need to look at the approach more carefully.

I've committed the 9.6 patch, but leaving open for further thought on 9.7

Simplified version of the repro added to the w3c test suite as insn/stream-500