Saxon

So we've established why it fails in the SEF case.

Why doesn't it fail when executed directly?

The answer is that the user-defined-function test-zos() is being evaluated eagerly because it is known to return a singleton. (Saxon uses a heuristic here that lazy evaluation delivers no benefits for a function that returns a singleton. This isn't always true, but it's a reasonable guess, and whether or not it's the correct strategy from a performance perspective is irrelevant to this bug.)

So it seems there are two separate issues here.

Firstly, when we invoke a function with ?void=this we should make sure that any Closure supplied as the argument is materialized, so that we only evaluate it once.

Secondly, we should look at why the execution strategy for lazy evaluation with a SEF file ends up being different from the original strategy. Have we lost some type information that is used for run-time decision-making?

We can solve the first problem by adding the line

argValues[0] = SequenceTool.makeRepeatable(argValues[0]);

before

theInstance = getTargetInstance(argValues[0], context);
// (JavaExtensionFunctionCall line 540)

It seems the difference between the .xsl and .sef paths is that on the .sef path, the staticType field of the UserFunctionCall object is null. This has the consequence that the cardinality of the result is unknown, which means that lazy evaluation is used.

The static type is computed during the type checking phase. It is not exported into the SEF file, and no attempt is made to recompute the value when the SEF is reloaded.

This can be fixed by adding the line

((UserFunctionCall) call).setStaticType(((UserFunction) c.getActor()).getResultType());

into the PackageLoader's fixup phase.

Although the UserFunctionCall expression is a little unusual in retaining the static type as an explicit property of the expression, there are other expressions that retain similar derived properties for use at run-time and the problem might be more general.