are used ... beside that, i am not sure, how access to specific parts of the repository can be restricted ...
You don't have to restrict anything. If someone messes with your work, you simply don't merge what they did. They're free to do whatever they want in _their_ repository, but you're not forced to accept it into _your_ "official" repo for your project.
Of course, other people would still be free to check out what the other guy did, even if it's not officially part of the main tree. The trick here is to think in terms of "pulling" rather than "pushing". Since no one is pushing, no one can step on anyone else's toes.
Anyways, I think under a system like git, the Pd kernel would have its own repo, and other subprojects (abstraction collections, externals, libraries) would have their own repos. A project like "Pd extended" could then simply be a "super-repo" collecting specific repos as submodules. Each submodule would be tagged to a specific version/branch.
I totally understand the hesitation, git does seem somewhat complicated at first. Once I finally understood the whole distributed way of thinking though, I couldn't help but dive in, and now I like the idea so much I think I can't go back... and actually, I discovered that the interface is really not that hard. Mostly you just use "clone", "pull", and "commit".
Another nice thing about it: you don't even have to "officially" switch all at once. Someone can just start a git repo based off the CVS, and you can go from there... whoever does that is responsible for keeping his repo up-to-date with the CVS and vice-versa. He can check his changes back into the CVS whenever he wants but still work with git on his own computer. It allows for a gradual weening away from the central repository instead of requiring everyone to switch at once.
I won't try any more to push the idea, but I think it's worth considering.
Steve