Dependency management is more than 'defining and getting dependencies'. What if package X relies on version 1 of package A, and and package Y relies on version 2 of package A. Will they work together, each in an isolated sandbox, or will you have dependency conflicts?
Package management is a really difficult problem to solve, which linux package managers have barely been able to solve. In addition to this, each programming language usually has its own package manager again, which vary a lot in quality.
Linux repositories conflates package management and (library/ABI) dependency management.
Windows already has locally deployed assemblies and central side-by-side (SxS) assemblies that can accommodate multiple versions of the same assembly, complete with major/minor versioning, redirection etc. Windows Installer supports reference counting and automatic uninstalling for the centrally deployed assemblies.
This new OneGet package manager is for solving the availability and automatic updating of packages. But Windows is not going to need separate repositories for each incremental update of Windows and the ABI.
no - this is not applicable to Windows, since there is not a widespread practice of system installed libraries. Windows packages are far more similar to something like 0-install (http://0install.net/).
If there are two software packages which depend on different version of a third party package, then the usual practice is that either the third party DLLs are included in the package or both the versions are specifically installed.
I think this is the way that OSX works as well - it is only Linux that works with centralized dependencies, which is what needs a very sophisticated dependency management solution.
It looks like they are basing OneGet off of NuGet - their package manager for Visual Studio. It does handle dependencies and is actually quite good compared to other package managers.
