The working group requested to see a more detailed example of the problem. After a few tries and some help in the last telcon (July 11, 2013) I revisited the following example in this mail (https://lists.w3.org/Archives/Member/w3c-xsl-wg/2013Jul/0022.html):

<xsl:value-of select="outermost(.//table/caption)"/>

The analysis (copy from the mail, copied here for people without access to the mail archives):

Analysis revisited (very detailed, to make sure I bring my thought
process across):

1. Determine the syntactic context (19.3.1).
1.1 outermost() is an "inherited context"
1.2 the inherited context is a pseudo context, look at the containing construct
1.3 the construct is the select-attribute of xsl:value-of 
1.4 this is a node-value context

2. Determine whether xsl:value-of is streamable
2.1 The rule under 19.3.4 states: look at General Rules for Streamability
2.2 The sweep requires to look whether the subsconstructs are consuming or motionless
2.3 Here, the only subconstruct of xsl:value-of is the select-attribute

3. Determine whether the expression in the select-attribute is motionless or (group-)consuming
3.1 Because of the inherited context, we must look at the inner expression .//table/caption
3.2 The expression is a RelativePathExpr [35] under 19.3.7
3.3 Rewrite the expression as ./descendant-or-self::table/caption
3.4 The new rule (1) states we can ignore . and should look at the other operands
3.5 We know from 1.4 above that this is a node value context, see rule (4)
3.6 Rule (4) requires to determine whether the expression is incrementally consuming

4a. Determine whether the expression is incrementally consuming
4a.1 Under 19.3.8 we find that each step must be a child-selection expression or a call to outermost()
4a.2 Currently, we look at descendant-or-self::table/caption
4a.3 This expression is not incrementally consuming

4b. Determine whether the expression is incrementally consuming
4b.1 We include outermost() in our expression analysis
4b.2 The expression to investigate under 19.3.8 is now outermost(descendant-or-self::table/caption)
4b.3 Under (3) we find that we need to determine whether the argument of outermost() is consuming

5. Determine whether .//table/caption is consuming (following 4b)
5.1 Rewrite to descendant-or-self::table/caption (see 3.3 and 3.4 above)
5.2 The context is unclear after step 4b.3
5.3 Assuming node value context, rule (4) brings us back to 4a or 4b

It turns out that, using this analysis, it is not possible to determine whether outermost(expr) is streamable or not. The main problem manifests itself when trying to determine whether the node value context is incrementally consuming, which brings us into an eternal analysis loop.

Another hickup in the analysis is knowing when to look at the whole expression (including outermost(), as in 4a vs 4b) or look at the expression of the first argument. The way inherited context is described, it seems like you should look at the inner expression, and not at outermost().

Note that, following the same logic, <xsl:value-of select="innermost(.//table/caption)" /> isn't streamable either, yet for another reason: 4b is not an applicable move, so 4a is the final rule that determines that this expression is not streamable. In the case of the inherited context for subsequence(), this is logical, because it could return overlapping nodes. In the case of inner/outermost, this doesn't seem the way to go, because overlapping nodes are not possible with these functions.

Resolved by adding a new rule to FunctionalCall [58] to allow functioncalls that are incrementally consuming.

Closed as per the minutes of F2F New-York 2013-07-31