Spack environment recovery after a failed upgrade: lockfile re-concretization vs. preserving the old environment view

I manage a Spack environment (spack.yaml + spack.lock under version control) and want a reliable recovery path when an upgrade of a core spec (for example a new compiler or MPI) fails concretization or build. Spack has no built-in rollback command, so the plan depends on installs being immutable and the old DAG remaining usable.

The constraint I cannot resolve: re-concretizing an old spack.yaml on a newer Spack release may not reproduce the original dependency versions or hashes, because concretizer output and package.py definitions drift across releases. Keeping the old environment's view intact avoids that, but only works if the old specs are still installed — and spack gc would remove anything no longer referenced, destroying the fallback.

Assuming a recent Spack release (0.20+), my questions are:

• Should recovery be based on restoring the committed spack.lock and reinstalling from it, or on keeping the pre-upgrade environment untouched so its view and hashes survive?
• Is pinning the exact Spack release alongside the lockfile sufficient to make lockfile-based recovery reproducible, or can hashes still differ?
• What is the safe ordering relative to spack gc and spack clean so the fallback spec and its build stage are preserved until the upgrade is verified?