Reuse installed specs or force a fresh solve for a repeatable Spack environment?

A Spack environment pairs an abstract manifest (spack.yaml) with a concretized lockfile (spack.lock); the lockfile is what makes the setup repeatable elsewhere. The open piece is how the concretizer should treat packages already present in the local store.

The trade-off

Recent releases favor reusing installed specs by default, though the exact default has shifted across versions. Reuse makes builds cheap and lets contributors share binaries, but it ties the lockfile to store history: two machines concretizing the same manifest against different stores can resolve different DAGs, so spack.lock stops being a pure function of spack.yaml. A forced fresh solve restores manifest-only determinism at the cost of rebuilds.

unify: true adds a second axis: one shared DAG keeps the environment internally consistent but can fail to solve under conflicting constraints, while per-spec solves stay flexible. Separately, a filesystem view versus module-only activation changes how the environment is consumed, not the DAG it resolves to.

For a shared development environment where every contributor should resolve to identical hashes:

• Should reuse be disabled outright, or is a canonical first solve committed to version control enough?
• Does reuse interact differently with unify: true than with per-spec solves?
• Since which Spack release has reuse been the default, and did that default change between 0.19 and 0.21?