> just mind-boggling how the dependencies are recorded and the default logic for picking which repo to use It makes some sense actually, For starters this is

> just mind-boggling how the dependencies are recorded and the default logic for picking which repo to use It makes some sense actually, For starters this is an immutable artefact: https://www.nuget.org/packages/Newtonsoft.Json/12.0.2 https://www.nuget.org/packages/Newtonsoft.Json/12.0.2 "Newtonsoft.Json 12.0.2" will always refer to the same bits. If you fix a bug in it and ship different bits, well then that's now e.g. "Newtonsoft.Json 12.0.3". There is security in immutable artefacts, you can detect tampering, with checksums. > having never used any internal package registry Internal package registries are useful a) for caching what can be large requests that repeatedly download the same bits and b) managing internal code, rather than huge projects or monorepos. So they are useful when codebases get large. Several vendors make products that you can deploy for this: JFrog artifactory, MyGet. Azure and Github both have hosted package feeds. It is not mind-boggling at all that you don't want someone making an internal package called "Newtonsoft.Json" - that way lies confusion. Especially if the internal feed will "fall back" to read-through caching a public feed. So the logic in package management is generally that a name such as "Newtonsoft.Json" is considered the same package _globally_ , if you get it from an internal feed or not. Source is typically considered irrelevant. So "Newtonsoft.Json 12.0.3" must be an update to "Newtonsoft.Json 12.0.2". And of course that's now the problem: deliberately doing the thing that you shouldn't do is how you break systems. The clever part is doing it the other way around by guessing an internal name and hosting it on a public feed with a later version. I guess supply chain attacks are getting more scrutiny now after the SolarWinds thing? The worst thing that I have seen a company to itself do regarding package naming is to fork a whole system, into call it "US" and "EU" codebases, with subcomponents, and either their own (internal) package feed. But not many things were renamed in that, so the US feed "Customer.Client" package and the EU "Customer.Client" package diverged over time, became incompatible. One shipped more iterations than the other so had a higher version number... After the next re-org a few years later there of course was a drive to consolidate, and of course this meant using both feeds. It's the kind of chaos and confusion that can only be solved by "well, don't F**ing do that in the first place, silly".