If I wrote up a document on this and all other evaluations I perform I'd have no time for work and I might unwittingly cloud the issue in the future by providing a checklist of problems for poorly reviewed VCS to quickly gloss over. So, evaluate them yourself.
Do the hg tutorial with bzr and hg, skipping the export section. You can add darcs and monotone to your short-list if you want.
Then do some of your own evaluations, like a simple rename, dir rename, merging divergent branches where one contains a renamed file which the other branch made changes to under original name.
Finally, evaluate a simple de-commit of changes.
Keep and eye on "log" (bzr/hg) and "changes" (darcs) when evaluating.
This takes less than an hour for each. You should find the results telling.
You should find bzr ui and functionality superior, but if you don't there's no need in anyone changing your mind, use what you like. In the end, I like mercurial for almost indescribable reasons, it has a better name and a more admirable history, but I can find solid technical reasons not to use it. I can find less (or no) technical reasons not to use bzr. I do believe it makes sense bzr is functionality and ui superior.
I evaluated hg, bzr and darcs fully, but discarded monotone early because I didn't like the ui. bzr, hg and darcs are all great and at a different time in their lives as products I might be inclined to pick any of them. But, I need VCS right now, and right now it seems bzr is the best choice.
You do not need any cygwin stuff for hg, bzr or darcs. If you find anything related to cygwin, skip it and look elsewhere. The bzr homepage is admittedly confusing, especially when it comes to downloads, some pages need to be deleted.
P.S. I just learned bzr shared repos are like mercurial's multi-heads (and perhaps less prone to human error).
It looks like mercurial's Windows support is even worse if you use the official source distribution. Some of that obviously makes its way through even in the Windows-friendly package from Bryan O'Sullivan.
I noticed this as I am now evaluating the ease/difficulty of contributing to each project (I even get to fix the same thing in both bzr and hg).
However, I will need to fix even basic things like "hg diff" in Windows if I want to contribute other Windows fixes. I didn't have to do anything like this using bzr, because the core distribution already works in Windows.
Do you want VCS, or DVCS? If you don't need distribution, or can live with a centralized repository with a lightweight network protocal and the ability to work detached, the there's a clear winner that nobody has mentioned yet: Perforce. Yeah, it's commercial. But they'll give free licenses to open source projects. They support more platforms than most OSS projects. Lots of add-on and extras. Lots of flexibility. It doesn't leave turds in your workspace. A command name (p4) that's as short as mercurials.
And the kicker - it's the only VCS I've ever encountered that gives me the kind of control I really want over a merge. After doing merges with perforce, every other VCS feels like I'm throwing my code against the wall, and hoping the right parts stick.
You can make "p4 resolve" act like other VCS merge commands, and merge everything it can and let you deal with conflicts. Or you can get an interactive loop, where you get told about the potential merge, can examine the files, or the automated merge, and choose to use anyone one of those three, or edit any one of those three and use that.
I can - and regularly want to - do things with perforce's merge that are at best very painfull, and in some cases impossible, with other VCS systems. If a VCS can't do the equivalent of "p4 resovle -at", it isn't going to replace perforce for me.