Spack environment concretizer: limits of unify false vs true for shared dependencies

Choosing a unify mode for a multi-root Spack environment

I maintain a Spack environment with several root specs that share common dependencies (MPI, BLAS, compression libraries). The documented behavior is that with concretizer: unify: false each root is concretized independently, so the same dependency can appear at multiple concrete versions in one environment. With unify: true the solver must produce a single shared DAG, and if two roots demand incompatible versions of one dependency, concretization fails outright instead of splitting the graph. A middle option, unify: when_possible, shares where compatible and falls back otherwise.

The uncertainty is which tradeoff to standardize on. Independent concretization maximizes the chance every root gets its preferred versions but inflates the install tree and complicates module loading. Full unification guarantees one consistent stack yet makes the whole environment unsolvable the moment any root pins a conflicting version, and when_possible makes results less predictable across re-concretizations. Changing the mode also rewrites spack.lock on the next spack concretize, so the choice affects reproducibility for everyone sharing the environment. I am on a recent Spack release but have not pinned the exact version, and I understand defaults here have shifted across releases.

Is there a documented or community-accepted criterion for picking a unify mode per environment, beyond trial and error? Does when_possible guarantee stable lockfiles across repeated concretization, or can the split point drift? Are there practical limits (root count, DAG size) where unify: true becomes too restrictive to maintain?