Lock-file deterministic restore vs explicit version downgrade for NuGet rollback reproducibility

Goal is safe recovery from a breaking NuGet upgrade in an SDK-style project using PackageReference, with reproducibility across developer machines and CI.

Two documented approaches exist. Lock-file deterministic restore relies on a committed packages.lock.json and locked-mode restore to detect any change to the resolved graph before build. Explicit version downgrade updates the direct PackageReference to a previous version and restores from that declaration.

The trade-off involves transitive consistency versus adoption cost. Lock files preserve exact transitive versions and prevent silent floating upgrades, but require team policy on committing lock files and consistent SDK behavior. Manual downgrade is simpler for a single direct dependency but does not guarantee transitive consistency when version ranges remain.

Guidance on when to enable and commit lock files for applications versus libraries is ambiguous, and interaction with floating versions and central package management varies by SDK.

Under which conditions does locked-mode restore provide a safer rollback signal than an explicit downgrade? How should teams decide lock-file policy for applications versus libraries? What consistency guarantees remain when central package management is used with either approach?