Inconsistent package version resolution with floating version ranges in NuGet restore

When a project declares a dependency using a floating version range (for example, [1.0,)), the NuGet restore process may resolve different applicable versions on different machines or after clearing the local cache, even when the same package sources are configured.

This behavior appears to depend on factors such as the order in which package sources are queried, timestamps or metadata associated with available versions, and the internal heuristics NuGet uses when multiple versions satisfy the range, especially when no lock file is present to fix the selection. The exact combination of conditions that leads to a non‑deterministic pick is not fully documented, making it difficult to predict which version will be used in a given environment.

• What specific criteria does NuGet evaluate to choose a version when several satisfy a floating range?
• How do package source ordering and version metadata influence the selection outcome?
• Can the restore process be made deterministic without relying on a lock file?