Saxon

The logic implementing this xsl:message instruction is surprisingly contorted.

xsl:message evaluates its select attribute and/or sequence constructor in pull mode, that is by calling iterate(), and then sends the returned items to the target Receiver using the append(item) method.

Because in this case the content of xsl:message is an instruction that likes to be evaluated in push mode, the instruction constructs a tree and then returns its root element node. The message receiver's append() method then decomposes this tree back to a sequence of events that are sent to the message receiver. Since the message receiver is essentially a raw XmlEmitter, there's no logic on this pipeline to eliminate redundant namespace events.

I would think it's almost certainly more straightforward for xsl:message to evaluate its operand in push mode (using the process method) to avoid building the intermediate tree.

But the central problem, I think, is that the events should be pushed to the message emitter via a NamespaceDifferencer, which would handle the namespace deduplication.