.NET 10 fails restore on a versionless PackageReference, and the reflexive fix breaks CPM

The diagnostic cannot tell two opposite faults apart, and that is the part worth engineering around. A missing version and a correctly centralised version are the same XML ^[3]. Restore emits the same NU1015 whether a developer forgot to pin a package or a repository stopped importing the file that pins it, and the NU1015 documentation names the second case directly: a project that expected Central Package Management ended up somewhere CPM is off or its props file is no longer found ^[4].

The discovery rule is what makes that failure mode easy to hit. NuGet imports only the first `Directory.Packages.props` it encounters while walking up from the project, so a nested props file added for one subtree changes which policy governs everything under it, and a project moved to a new path can lose the import outright ^[6]. Neither event edits a single project file. That is why the dev.to walkthrough checks evaluated project inputs, neighbouring props files, and recent path changes before touching any package metadata ^[7]. The timing of the failure is a poor witness: an SDK upgrade surfaces an old direct reference that had always coasted on lowest-version resolution, while a repository reorganisation breaks a CPM import that was valid the day before ^[8].

The sample feed is where the old behaviour gets priced. It carries Demo.Greeting 1.0.0 and 2.0.0 ^[9]. Both supported repairs, a pinned `Version` on the reference and a `PackageVersion` in the nearest central file, must resolve and run 2.0.0 ^[10]. Restore the broken project with `-p:SdkAnalysisLevel=9.0.300 -p:TreatWarningsAsErrors=false` and NU1604 returns, and NuGet picks 1.0.0, the lowest available ^[11]. A full major version separates the lenient path from the repaired one on a two-package feed ^[17], which is a fair account of what the warning was permitting in repositories nobody was watching. The author reserves that switch for short migration diagnostics, since it moves every SDK behaviour gated at 9.0.300 along with the one you wanted ^[12].

The test discipline in the sample is the transferable part. The verifier packs both fixture versions, runs each restore, reads `project.assets.json`, and executes the repaired projects, asserting the resolved version rather than a successful restore ^[10]. A pasted version and a working CPM import both produce a green restore; only the resolved version tells you which one you shipped.

Two caveats sit on the edges. Repositories that already treat warnings as errors never had the lenient path to begin with, because that policy could promote NU1604 to a failure on its own ^[13]. And the local-feed sample deliberately skips authenticated sources, source mapping, package lock files, and feed outages ^[14], all of which sit between a passing fixture and a production restore.