The Version Control System dependency problem
One of the aphorisms of HCI design is that if users keep making the same error with a program, it's the program and not the users that's actually wrong. By this standard, almost all version control systems really need an HCI makeover, because there is one classical mistake that users keep making over and over.
The mistake: make a change, then make an unrelated change, then make a third unrelated change (perhaps fix three different and independent bugs in entirely different files). You get a version diagram that looks like:
Original -> B -> C -> D
Now try to pass just the third change to someone, using the version control system. Almost all version control systems will refuse, saying that the C to D change depends on C (which depends on B), and you can't pass D without its dependencies.
(The 'proper' way to do this is that you should have put each change in a separate branch (or equivalent), then merged them together to get something you can test.)
But these are unrelated changes and the VCS is wrong, because most VCSes have adopted an extremely simplistic idea of dependency: if C comes after B in the same branch, it depends on B. In turn, this simplistic idea clashes with how normal people try to use VCSes before they get inoculated with the version control religion.
And this is the VCS dependency problem: VCSes are too strict about 'dependencies', so much so that it gets in people's way. Clinging to mathematic purity may have a clean intellectual appeal, but it comes at the expense of practical usability.
In practice it also comes at a cost of damaging the integrity of the codebase's history. People will make these kinds of mistakes and have to fix them; the only question is whether they will be able to do so inside the VCS or whether they will resort to exporting and importing patches and the like (with the loss of some of the development history).