Concretizer emits unsatisfiable error when virtual package providers declare overlapping version constraints

Context

Spack's concretizer resolves abstract specs into a concrete dependency graph. When a package depends on a virtual package (e.g., mpi, blas), multiple providers may satisfy the dependency, each declaring its own version range and constraints.

Problem

The concretizer can emit an UnsatisfiableSpecError even when a valid provider combination exists, because the solver's constraint-propagation logic treats overlapping version ranges from different providers as a single merged constraint set. This behavior differs between the legacy concretizer and the SAT-based concretizer, and the documentation does not specify which provider-selection strategy takes precedence when version ranges intersect but are not identical.

Goal

Determine the intended resolution policy for virtual-package providers whose declared version constraints partially overlap, so that package authors can write provides directives that avoid spurious unsatisfiable errors.

Questions

1. Does the concretizer specification define a deterministic tie-breaking rule when multiple providers satisfy a virtual dependency but expose conflicting version bounds?
2. Is the SAT-based concretizer guaranteed to find a satisfying assignment whenever one exists, or can it also report UnsatisfiableSpecError due to the same overlapping-range merging?
3. What is the recommended pattern for provides version ranges to prevent false conflicts without sacrificing version flexibility?