Here are some features I'd like to see in VCS that come from having used CVS, PRCS, SVN, Monotone, Darcs and eventually Mercurial.

Most of these features can totally be built on top of modern VCS and don't require building yet another program.

• Automatic commit population from file. When you make changes, annotate your files and the system will recognize the comments and generate the pre-generate commit message for you.
• Good looking tags, instead of $Version:$VERSION$ do something like Version:1.0 at specific locations and make the program detect and replace with the proper value. This could be preconfigured for languages (Python __version__).
• Rewriting history. You realized that you botched some changesets, either commit message or actual content. You've got a chance to undo, fix, and then redo.
• Changeset aggregation. You've made a bunch of changes, and realize they are part of a bigger thing. You can aggregate them to appear as one single patch (less clutter in the version history), while allowing people to expand the patch to see its detail.
• Changeset tagging. Sometimes you're implementing a feature; sometimes you're fixing bugs, less often you're writing documentation... but in every case you'd like to tell the system what you did (feature/bugfix/doc).
• Stats. It's really underestimated, but VCS are a gold mine for QA and projects managers. Which are the most active files, when appeared the unit tests, who wrote the documentation.
• Unit test integration. For each changeset, or major changeset, give the state of the unit tests. This implies some standard way of integrating unit tests to VCS.
• The holy grail: architectural changesets. If the VCS was able to understand (even basically) the architecture of the program, and to analyze the effect of the changeset on the program, it would be a very useful information for finding the possible origins of a problem.