Spack environment activation limits for in-place dependency upgrades

Goal is to move a small application to a newer version of a dependency while keeping existing sessions available. Spack environments can hold multiple concrete specs at once, and activation can be scoped to a shell. Binary mirrors are documented for distributing pre-built packages to reduce build time.

The design relies on the documented limit that activating a new environment does not affect processes launched from a previous environment as long as installed prefixes are not overwritten. A known unresolved behavior is that Spack does not automatically reconcile ABI incompatibilities when the compiler is changed within an environment.

With those constraints, what is the supported limit for concurrent environments sharing the same installation root during an upgrade? Does a compiler change within an environment require a full reinstall of dependents to avoid runtime ABI failures, and is there a documented way to detect those failures before activation? Does binary mirror usage guarantee that an upgrade can be applied without recompilation when architecture and OS match?