Distributed Version Control Systems (DVCSs) are getting a lot of attention lately, mostly because of the open-source Monotone project. You might be interested to know that it was Reliable Software who invented the first such system, your friendly Code Co-op. Larry McVoy's Bitkeeper was not far behind.
There is one important philosophical difference between Code Co-op and other DVCSs. Our goal was to create a distributed database of project changes. There is a replica of a project database on each computer. These replicas are being kept in sync by our system. So, conceptually, there is only one linear development process. This was a hard thing to implement, but that's what makes Code Co-op so unobtrusive and easy to use.
The user has a very simple and natural conceptual model. He or she collaborates with other project members on the same body of code. Such system is very well suited for small to medium teams of collaborators who have a common set of goals and communicate with each other. It's perfect for Extreme Programming.
Code Co-op's model, however, is not very well suited for open-source development, with its fluid membership and hit-and-run check-ins. What happens in many open-source projects (and is a source of no end of headaches) is that a developer grabs a snapshot of the project, works on it for months, and than drops a bomb on the rest of the team with one huge check-in. Both BitKeeper and Monotone not only support but virtually encourage this kind of methodology.
Those systems have a philosophy that's opposite of Code Co-op's. Instead of creating the perception of a single development path and a single (distributed) database, they allow each member to disconnect from the rest of the team. Their distributed database is really a set of virtually independent repositories that have to be synchronized by hand. That's why their ability to merge changes is so vital. Merging is the basic way of operation. That's why they brag so much about the cleverness of their mergers.
Of course, you have merges in Code Co-op too. But these are merges on the way down from the top. When a new change is made, it has to be merged into local sandboxes of other Code Co-op users. If you keep your sandbox clean, check-out only files that you're working on, and do frequent check-ins, there's very little merging to be done.
In other systems, merges have to be done on the way up, from the local, or low-level repository, up the hierarchical chain of repositories, all the way up. Unlike in Code Co-op, where the merge must be done to make the next check-in possible, those systems allow the users to postpone merges, often leading to something that is aptly called the merge hell. During a merge emergency, the management often prevents everybody from making any check-ins, sometimes for days!
Are these other systems more flexible than Code Co-op? In a sense, yes! By following strict rules and protocols, you might be able to use Monotone in a similar regime as you use Code Co-op--the same way you can use object-oriented paradigm in assembly. What you lose is the wonderful unobtrusiveness for which Code Co-op is famous. We love getting feedback from users, who say that they don't notice Code Co-op. It just blends in!
If you need an "assembler-grade" version control system, which you are willing to "program" to do what you want, Code Co-op is not for you. But if you don't have the time or resources to keep tweaking the system, Code Co-op offers a simple but very robust environment for collaboration.