Saxon

The main issue here seems to be that we don't have any streamability analysis code for xsl:message, and it is falling back to the default. (But I'm not sure why this doesn't give a streamability failure).

A secondary issue is that we aren't being smart about inferring the context item type for the match pattern match=".[. instance of ....]". There's justification for this, because the W3C spec doesn't handle it specially. But we could do better.

The streamability rules in 1.b.iii.A.I say

If U is absorption and the intersection of T with U{element(), document-node()} is U{} (that is, if T is a type that does not allow nodes with children), then U′ is inspection.

But (Streamability line 169) we are actually testing isChildlessNodeKind(), which returns false for items such as maps and atomic values.

This has the effect that even when we compute the context item type for this template rule as map(*), the reference to "." in xsl:message, which has usage absorbtion, is considered to be a "potentially consuming operand", leading to the select expression of the xsl:message instruction being classified striding and motionless. This in turn leads to the xsl:message being classified as grounded and consuming. Which in this case isn't fatal, but if there were more than one xsl:message instruction like this then we would get a "multiple consuming operands" streamability failure.

I've changed the test from isChildlessNodeKind() to !t.getUType().overlaps(UType.DOCUMENT.union(UType.ELEMENT)) and unfortunately this doesn't solve the problem. The arguments to xsl:message include both "." and various variables whose type can include element nodes, so the test that the value can't be an element or document node isn't satisfied anyway.

I can't help feeling there's a rule missing here somewhere: if the match pattern on a template rule doesn't match nodes, then the template rule must surely be grounded and motionless, regardless of its contents.