Saxon

This one looks quite tricky to fix. Currently the Mode object is being updated during the processing of XSLMode.prepareAttributes(), which is called early on (during spliceIncludes) while processing raw XSLT documents, before components have been sorted into precedence order. Ideally the properties on the Mode object just be set only during the XSLMode.compileDeclaration() phase.

However, the Mode object has a mechanism for dealing with this, namely the setExplicitProperty() method which captures the value of a particular property at a particular precedence. This mechanism is being used to check for conflicts between attribute values at different precedences, but (except for the @typed attribute) it isn't being used to ensure that the effective value is the one with highest precedence.

I've fixed this particular case on the 9.8 branch by resetting the property on the mode during the checkForConflictingProperties() method. This needs to be extended to other properties where the same problem can occur.

Detecting conflicting values of xsl:mode/@use-accumulators requires particular care because it's not a simple string. The spec doesn't really say what it means by "conflicting values" but I think it should be interpreted as "the same set of names".