Saxon

Actually, of course I can add the text of the entire template rule without giving anything away in a public forum:

<xsl:template match="adoption[c:metaOriginator(adoption-front/std-meta)=
                              $c:guestOriginator] |
                     standard[c:metaOriginator(front/std-meta)=
                              $c:guestOriginator]
                     (:remove the following for the client; this allows any
                       national content to be captured by this template rule:)
   | adoption[string(adoption-front/std-meta/@std-meta-type)=('','national') or
                 not(adoption-front/std-meta/c:metaOriginator(.)=
                     $c:internationalAndRegionalOriginators)]
   | standard[string(         front/std-meta/@std-meta-type)=('','national') or
                 not(         front/std-meta/c:metaOriginator(.)=
                     $c:internationalAndRegionalOriginators)]
                     (:up to this point:)"
              mode="c:determineToCentries" as="element()*">
  <xsl:call-template name="c:realtaPageDetermineToCentries"/>
</xsl:template>

I'm pretty sure you're right that this shouldn't happen.

However, it's not easy to find in the spec.

The rule that says this is treated as if there were multiple template rules is in §6.5:

If the top-level pattern is a UnionExprP consisting of multiple alternatives separated by | or union, then the template rule is treated equivalently to a set of template rules, one for each alternative.

The rule about conflicts is in §6.4

[ERR XTDE0540] It is a dynamic error if the conflict resolution algorithm for template rules leaves more than one matching template rule when the declaration of the relevant mode has an on-multiple-match attribute with the value fail.

I thought there was a rule that this error didn't occur if a node matched multiple alternatives of the same union pattern, but I'm having trouble finding it. In XSLT 2.0, §6.4 says:

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.

I can't find that "However..." in the 3.0 spec. I don't remember it being a conscious change, and it's not documented as an incompatibility, and I don't think it's a change for the better, but as far as I can see the 3.0 spec describes the behaviour you are seeing. Perhaps we felt we could change it because it's now only a hard error if you specify on-multiple-match="fail".

Union patterns in template rules are an absolute pain. What seemed a neat idea in 1.0 to match at two different priorities turned into a nightmare with the introduction of xsl:next-match in 2.0, and keeps getting more complicated. I would be quite inclined to avoid the whole nightmare by adding an explicit priority to the rule, which stops it being broken up.