PackageReference upgrade with lock file: reverting to prior dependency graph after failed resolution

A design question concerns returning a SDK-style project using PackageReference to a known good dependency graph when a version change leads to unresolvable or undesired transitive resolution.

PackageReference stores dependency versions in the project file and NuGet resolves the transitive graph during restore, writing project.assets.json and optionally packages.lock.json for reproducible restores. dotnet add package and dotnet remove package edit the project file directly, while restore does not roll back those edits if resolution fails. Lock file restore can detect a mismatch between the locked graph and requested versions. Central Package Management and Directory.Build.props change where versions are recorded, affecting which files participate in a revert.

There is no documented atomic transaction that reverts both the project file edit and the restored packages on a failed resolution. What is the supported behavior for packages.lock.json when the csproj PackageReference version is changed to an unresolvable value? Does restore enforce the lock file and reject the change, or does it update the lock? What differences in version recording arise under Central Package Management that affect which files must be reverted?