Moreover, and perhaps more seriously, the relevant text in XSLT 2.0 said:

If the pattern contains multiple alternatives separated by | , then the template rule is treated equivalently to a set of template rules, one for each alternative. However, it is not an error if a node matches more than one of the alternatives.

The last sentence has disappeared from the XSLT 3.0 specification. This would appear to mean that if you write

<xsl:template match="p[@class='heading'] | p[@style='bold']">

and xsl:mode specifies on-multiple-match="fail", then you will get an error if any p element matches both branches of the union. This seems unfortunate.

In §6.4 rule 3(a). after

If the mode M has an xsl:mode declaration, and the attribute value on-multiple-match="fail" is specified in the mode declaration, a dynamic error is signaled. The error is treated as occurring in the xsl:apply-templates instruction, and can be recovered by wrapping that instruction in an xsl:try instruction.

I propose adding: "However, no error is signaled if the matching template rules all form part of a set of template rules generated from a single xsl:template declaration whose match pattern is a union pattern (as described in §6.5 rule 2)"

I agree to your suggestion in comment#2.

Or as an alternative, we can remove the rule that a union pattern with '|' needs to be split into multiple template rules. I don't think the syntax is ambiguous if we remove that rule, and in fact, it should only be an implementation detail.

Removing the rule gives a backwards compatibility problem because match="doc | node()" is supposed to behave like two rules with different priorities.

It was probably a bad idea, but I think we're stuck with it.

Looks like my alternative proposal would change current behavior after all, so that's a no-go. In fact, we have a specific Note on xsl:next-match saying:

> a template rule with no priority attribute, whose match pattern contains 
> multiple alternatives separated by |, is treated equivalently to a set of 
> template rules, one for each alternative. This means that where the same item 
> matches more than one alternative, it is possible for an xsl:next-match 
> instruction to cause the current template rule to be invoked recursively. This 
> situation does not occur when the template rule has an explicit priority. 

This implies that union'ed template rules with different default priority would be called again when xsl:next-match is invoked. I never realized this behavior was even possible, I wonder if we have a test covering this specifically.

(In reply to Michael Kay from comment #4)
> Removing the rule gives a backwards compatibility problem because match="doc
> | node()" is supposed to behave like two rules with different priorities.
> 
> It was probably a bad idea, but I think we're stuck with it.

You came to the same conclusion at the same time ;)

Yes, there are next-match tests for this (that's what got me here, they weren't working in one particular Saxon configuration).