Saxon

A workaround is to change the group-starting-with attribute to

group-starting-with="*[boolean($starts.function(.))]"

(The problem arises because Saxon doesn't know whether $starts.function() might return a numeric value, and it therefore has to cater for the possibility; patterns involving a predicate where the predicate value is potentially numeric are much more complex to deal with.)

What's happing is that optimization of the function els:wrap-elements-starting-with-names attempts to inline the function els:wrap-elements-starting-with, and after inlining, the reoptimization of the xsl:for-each-group function now knows more about the supplied group-starting-with function, in particular it knows that it will return a boolean. So it tries to take advantage of this knowledge. In particular, this enables it to use a BasePatternWithPredicate rather than a GeneralPositionalPattern, which is a lot more efficient to evaluate because it doesn't need to know the sibling position of the node being tested.

Where this goes wrong is that the group-starting-with operand of xsl:for-each-group is labelled as a "constrained class" operand, which limits the ability to substitute an expression of a different class during optimization.

The intent of marking it as constrained is to guarantee that the output of a rewrite will always be a Pattern (which is implemented as a subclass of Expression; but it's not the case that any Expression can be used in this context). However, the constraint actually being enforced is that the expression produced by the optimizer must be the same class as the original - that is, the same kind of Pattern. The constraint is too restrictive.