Manual version downgrade vs. lock-file restoration for failed NuGet upgrades

After a NuGet package upgrade introduces breaking changes, the recovery decision is between a manual version downgrade and restoring a previously committed packages.lock.json. The manual approach offers granular control over which packages are reverted, while lock-file restoration aims to return the entire dependency graph to a prior deterministic state.

The constraint is how transitive dependencies are resolved when the graph is shared. Manual downgrades can leave dependency drift when other packages still require newer sub-dependencies, and the unresolved behavior is whether a parent downgrade automatically propagates to shared transitive nodes. Lock-file restoration provides graph-wide consistency but is only effective when lock files are enabled and committed, and it becomes difficult to merge when concurrent code changes or manual sub-dependency overrides are needed.

• Under what conditions does a manual version downgrade fail to revert transitive dependencies that are shared across multiple packages in the graph?
• What risks arise for lock-file restoration when the project has concurrent code changes since the failed upgrade?