"Should be possible" - indeed.

There is also a clear relationship to the rules for RelativePathExpr. This gives us an opportunity to examine why the rules for xsl:for-each and for RelativePathExpr are different. Let's look at the cases in turn.

1. For path expressions, we have the rule:

If either operand is a ContextItemExpr or a ForwardStep using the self axis, followed in either case by zero or more motionless predicates, then the sweep of the other operand;

which has no equivalent for xsl:for-each. It's very unlikely to arise with xsl:for-each, but does that mean we should leave it out? It certainly needs to be there for "!".

2. For RelativePathExpr we have the rule

If the first operand is motionless, then motionless;

For xsl:for-each the corresponding rule has additional qualifications: the first relates to xsl:sort, which is a reasonable difference, and the second relates to the use of group binding variables. This qualification is also relevant to path expressions. However, I think it can be simplified.

I think there's another bug here. Consider the expression (1 to 10)/current(). The first operand is motionless so we deem the expression as a whole motionless, regardless of the fact that current() is free-ranging. The issue here is that there are a small number of constructs, including current(), current-group(), and references to group binding variables, that can appear on the rhs of "/" (or in the body of xsl:for-each) and depend on the "outer context" rather than the "inner context" of the expression.

So I think this rule for RelativePathExpr needs to disallow references to grouping variables and to current() on the rhs.

3. Under RelativePathExpr rule 3, we have:

If the syntactic context is an inspection context and the RelativePathExpr takes the form of a RelativePathExprP that itself conforms to the rules for a motionless pattern (see 19.3.10 Classifying Patterns), then consuming;

Clearly there's no direct equivalent for xsl:for-each because an xsl:for-each instruction cannot take the form of a pattern. It's an odd rule though, especially as the example given - exists(descendant::section) - isn't even a RelativePathExpr according to the way we defined it. Somehow one feels this rule shouldn't be necessary; it should fall out from the other rules.

4. Under xsl:for-each rule 3, we recognize group-consuming constructs of the form 

<xsl:for-each select="$current-group"><xsl:value-of select="child"/></xsl:for-each>

We don't have any corresponding rule to recognize $current-group/string(child) as group-consuming; I can't see any good reason not to.

5. Rule 4 of RelativePathExpr and Rule 4 of xsl:for-each have similar effect but they are phrased differently and are not in fact equivalent. For example, the xsl:for-each rule recognizes 

<xsl:for-each select="a/b/c"><xsl:sequence select="name()"/></xsl:for-each>

but the RelativePathExpr rule does not allow a/b/c/name(). I think these two rules should be aligned.

The rewrite of the streamability rules following the Henley face-to-face means that this bug report is no longer relevant.