Saxon

Getting exact line and column numbers is always going to be a problem, because of the limitations of what SAX reports. As described at https://saxonica.plan.io/issues/6415#change-26038 I've recently been experimenting to see if I can associate an element with the location data from the previous SAX event rather than the current SAX event. That's giving good results overall, but doesn't work when there are multiple XML external entities (e.g. a DTD) - there's no way as far as I can see of getting an accurate position for a start tag that immediately follows a DOCTYPE declaration or an external entity reference. As the SAX specification clearly states, the best you can hope for is an approximation.

The issue with the match patterns arises here because Saxon, as required by the spec (XSLT 3.0 §6.5 para 2) treats a rule with a union pattern as two separate templates: "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. " It looks as if both are being given the same pattern for tracing purposes, based on the first branch of the union. I suspect that is easily fixed. (IIRC we try to output the pattern as written, not as reconstructed by reverse-compiling its internal form. But for a union pattern that has been split in this way, there isn't a version "as written", so we have to do something else.)

Right: complicated.

It's creating two separate TemplateRule objects that have different match patterns but share the same compiled Body representing the content of the template rule. The trace instruction on entry to the template is part of this compiled body, and it looks upwards to see what template rule it is part of in order to display the match pattern, and it happens to be linked to the first one rather than the second.

The answer to that would seem to be that the shared top-level trace instruction should contain the full match pattern before it was split into parts, but achieving that may be a bit fiddly.

The logic is at XSLTemplate line 788. For the first template in a group (derived by splitting a union pattern), the body is compiled from scratch, and then trace code is injected. For subsequent templates in the group, the body (including the trace instructions) is deep-copied (this is so that the optimizer can handle each branch individually, using knowledge of the context item). This is why the trace instructions reflect the first match pattern. The solution isn't obvious.