I think this error is not needed in the first place, so I would like to consider dropping the error entirely (your A2 above). Though I am not sure it should apply the imports from the used package, since it is used in the using package in xsl:override, it seems to make sense to have xsl:apply-imports apply to the imports scoped to the using package. 

This is somewhat similar to, say, a named xsl:output, which can only be referenced from within the using package (in case of xsl:override), but you can never access the named outputs from the used package. It seems odd if use a different rule for xsl:apply-imports (apart from the fact that, if the package is compiled, its imports may not be available anymore).

> it seems to make sense to have xsl:apply-imports apply to the imports scoped to the using package

The using package cannot define any template rules for the relevant mode outside the xsl:override element itself. So if we adopt this rule, the eligible set of template rules would always be empty. That doesn't necessarily make this suggestion non-viable, since we allow xsl:apply-imports in other situations where this is the case, e.g. in a module that doesn't import anything.

I think an error is probably the better option, but it has to be a dynamic error given that the current template rule and current mode survive calls of xsl:call-template.

After discussion, the WG decided to go with the option that xsl:apply-imports is permitted, and is effectively a no-op (because the set of candidate template rules to consider is inevitably empty).

The effect is to delete the paragraph

[ERR XTSE3460] It is a static error if an xsl:apply-imports element appears in a template rule declared within an xsl:override element. (To invoke the template rule that is being overridden, xsl:next-match should therefore be used.)

and replace it with a note:

Note: If xsl:apply-imports is evaluated when the current template rule is declared within an xsl:override element, the set of candidate template rules will always be empty. This is because template rules for the relevant mode cannot be declared anywhere in the using package other than within the xsl:override element itself. 

The problems in (B) and (C) will also be fixed.

In relation to (B), note also that an xsl:use-package can have more than one xsl:override child, and that multiple overriding template rules for a given mode are therefore not necessarily siblings of each other.

The wording I have adopted is:

<quote>
Because a template rule declared as a child of <elcode>xsl:override</elcode> has higher precedence than any template rule declared in the used package (see <specref ref="modes-and-packages"/>), the effect of <elcode>xsl:next-match</elcode> within such a template rule is to consider as candidates first any other template rules <phrase diff="chg" at="S-bug29210">for the same mode within the same <elcode>xsl:use-package</elcode> element (taking into account explicit and implicit priority, and document order, in the usual way), and then all template rules in the used package.
</quote>

Concerning (C), I am inserting the following before the paragraph "If no matching template rule is found" in section 6.8:

<quote>
If a matching template rule R is found, then the result of the xsl:next-match or xsl:apply-imports instruction is the result of invoking R, with the values of parameters being set using the child xsl:with-param elements as described in §9.10. The template rule R is evaluated with the same focus as the xsl:next-match or xsl:apply-imports instruction. The current template rule changes to be R. The current mode does not change. 

Note: In the case where the current template rule T is declared within an xsl:override element in a using package P, while the selected rule R is declared within a different package Q, and where the current mode is M/P, the effect is that the current mode for evaluation of R remains M/P rather than reverting to its corresponding mode M/Q. If R contains an xsl:apply-templates instruction that uses mode="#current", then the set of template rules considered by this instruction will include any overriding template rules declared in P as well as the original rules declared in Q.
</quote>

In relation to (B) I noticed another place where we make the same error.

§3.5.4, list item 1, says:

Rules declared within P (specifically, xsl:template rules declared as children of the xsl:override element within the xsl:use-package element that references package Q). If there are multiple rules declared within P that match a selected node, the last one in declaration order wins.

It should say:

Rules declared within P (specifically, xsl:template rules declared as children of an xsl:override element within the xsl:use-package element that references package Q). If there are multiple rules declared within P that match a selected node, they are resolved on the basis of their explicit or implicit priority, and if the priorities are equal, the last one in declaration order wins.

The WG confirmed today that this has been resolved.