A package manager really sounds like the sort of project where the incompatibilities between *nix and Windows are large enough that writing a new one would make more sense. I think there are even existing projects like that for Windows; I remember seeing one on HN a while back, but can't recall the name.
Instead of reinventing its own selfupdate functionality, Homebrew just uses git. Updating Homebrew is really just fast forwarding a git repository. Finally, the maintainers explicitly do not duplicate the libraries/tools that ship with OS X.
This is a big step up on OS X from Macports, which installs itself in /opt/local and rebuilds everything possible. Homebrew is instantly understandable. Packages are files, you just match them by name. apt is admittedly more complex, but at least you get something for that complexity.
[1] really what's slow is building from source. Homebrew itself is very fast.
In fact, MacPorts actually supports generating Debian packages and an apt repository straight from its port files.
As for Windows, Cygwin already provides binaries. An apt repository of them would be great. I'm not convinced porting homebrew or MacPorts makes sense, however -- they're both fairly Mac-focused.
It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.
I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view.
If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on.
The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.
(Honestly: what does Homebrew make simpler than MacPorts anyway? Near as I can tell, the only reason people seem to like it is that it doesn't take as long to compile software, which argues more strongly to me that we need binary distributions that can download pre-compiled copies than that we should attempt to use the libraries to save installation time.)
1. No alternative copies of Python, Perl, Ruby, zlib, etc...
2. Everything installs to where it is supposed to, i.e., under /usr/local/
After installing via Homebrew, things do not look drastically different to having compiled them by hand.
Fink does install precompiled binaries: http://www.finkproject.org/
If you think there is no complexity issue with sandboxes, try using both Macports and Fink side-by-side.
And if I need a newer version of Python, coupled with a dependency tree of third-party modules?
I don't see why this matters, other than some pedantic sense of cleanliness ("NO DUPLICATES!" ... even though they're not, in reality, duplicates).
2. Everything installs to where it is supposed to, i.e., under /usr/local/
You can configure MacPorts to do this, but the reason it's not the default was to leave /usr/local for the user's own manually installed software. I don't think this really matters either way.
After installing via Homebrew, things do not look drastically different to having compiled them by hand.
I don't know what this means or why it matters.