one thing I don't much like are packages that require users to get a bunch of software and load it before they can get the package. I like to minimize barriers to entry, and we probably have all seen situations where to get package Y, you need to get package X, which doesn't work on your system Z due to conflicts with language/compiler A, B, and C.
darcs requires people to get a Haskell and build it. Not so sure I like this.
arch is a single C program but if we are really proposing changes I'd rather not end up with maintaining an RCS as part of the project, so I think the changes should go back into arch if they're really needed.
In the end, what does arch do better than bitkeeper? I'd like to understand that. bk is used for the Linux kernel itself, as well as the infiniband source tree, which indicates to me that it is fairly robust. bk has the same problem as darcs and arch, however: users will need to get these and get them working before they can get etherboot/linuxbios. The infiniband project fixed this by exporting to sourceforge. But sourceforge was failing again for me today, so depending on that seems a mistake.
The 'arch' web pages have a few 'we need help' items, which leaves me somewhat concerned.
Is the motivation here perceived problems with CVS (not hard to imagine) or with sourceforge (also not hard to imagine).
ron