Saxon

I think the critical factor here is probably that xsl:next-match is called from within a named template, which means that the current component is the named template, while the current mode is the mode of the template rule from which the named template was called. When next-match invokes a built-in template rule, I don't think the current component is being changed, whereas I suspect it needs to become the same as the current mode.

A workaround is to add an explicit template rule equivalent to the built-in rule:

    <xsl:template match="node()" priority="-1">
        <xsl:apply-templates/>
    </xsl:template>

I've made a fix which appears to do the trick subject to further testing: in the process() method of the three relevant BuiltInTemplateRuleSet implementations (ShallowSkip, ShallowCopy, and TextOnly), when creating a new XPathContext object prior to the applyTemplates call, set currentComponent to be the same as currentMode.

It seems that applyTemplates always creates a new XPathContext object even when calling the built-in template rule - it has to, because it might be processing multiple nodes, some with explicit template rules and some with the built-in template rule. NextMatch and ApplyImports, however, don't create a new context object when using the built-in template rule, they rely on the code for the built-in rule to do it when necessary. I think this means that on the applyTemplates path we might be creating two new XPathContext objects, which is an unnecessary cost.

There's definitely a need for more testing here.

Bug fix applied in the Saxon 9.8.0.7 maintenance release.