Saxon

Let's try and explore the consequences.

We need a mode attribute on xsl:template or xsl:apply-templates that's a space-separated list of names; such a list is going to be processed as a single name. Parsing this as a QName will fail, and the exception is ignored (on the basis that this routine isn't responsible for validation, that's done elsewhere). So the net effect is that when xsl:template contains a list of mode names, these modes won't be automatically registered. If there's an apply-templates that uses the mode name, this isn't going to matter because the apply-templates will register it. So it's only the case where the mode name appears in an xsl:template element and not in an xsl:apply-templates that matters: in this case presumably the mode won't be eligible for selection as the initial mode. So I'll try and create a test where a template has two modes and one of them is used (only) as the initial mode.

Created test initial-mode-005 using

<xsl:template match="a b c">...

but it doesn't fail. The fact that registerImplicitModes() fails to register the mode doesn't matter, because it gets registered anyway by XSLTemplate.compile(). In fact, it seems the only reason we are doing the registerImplicitModes() scan is to deal with modes that appear only on xsl:apply-templates, and in such cases only a single mode name is allowed, not a list.

Conclusion: the bug has no observable consequences other than the performance impact of raising and ignoring unnecessary exceptions.