Spack Tcl and Lua module generation: conflicting modulefile precedence when the same package is built with different compilers

We generate both Tcl and Lua modulefiles for the same Spack installation (0.20+) using spack module tcl generate and spack module lua generate. Several packages exist in multiple variants built with different compilers, and our modules.yaml defines projections and conflict rules that we expect to apply uniformly.

The uncertainty is at the integration boundary between the two generators: when the same module name is requested through different compiler settings, the resolution appears to depend on ordering rather than on an explicit precedence policy. Concatenated modulefile fragments seem to follow a last-match-wins rule, while environment module selection appears to pick the first match. This makes it hard to predict which compiler wrapper a user session will actually load, and we have seen indications that an incompatible wrapper can be selected silently.

We assume Spack 0.20–0.22 behavior and plan to verify by generating both module types for one package and inspecting the emitted files and resulting environment variables.

1. Is the precedence ordering between Tcl and Lua modulefile fragments a documented, stable behavior or an implementation detail that may change between releases?
2. Is there a supported way in modules.yaml to make compiler-based conflict resolution deterministic across both module systems?
3. Should first-match versus last-match semantics be considered a bug when they diverge between the two generators?