Strict vs. Default Concretization for Complex Dependency Trees

When managing large software stacks in Spack (v0.20+), the concretizer must resolve abstract specifications into a concrete build plan. There is a documented trade-off between using strict version enforcement and the default loose resolution strategy.

Strict concretization limits the search space by enforcing exact version matches, which typically reduces resolution time. However, in environments with deep dependency chains or conflicting version constraints, this approach increases the likelihood of unsatisfiable dependencies.

Conversely, the default concretizer explores a wider range of compatible versions to maximize the probability of a successful build, but this can lead to exponential growth in the search space and significantly longer resolution times.

• Does the strict approach consistently prevent the concretizer from hanging in deep dependency trees?
• Under what specific constraint density does the default concretizer's search time become prohibitive compared to strict enforcement?