We can use the VCS to get version information. If a project doesn't tag releases in version control then screw them -- it's 20freaking10.
Doing this makes updating packages really easy, we just pull down the newest version of the repository, remove the previous symlinks, update to the given version, rebuild and symlink.
Projects where the symlinking requirements change over time could be tricky though. We'll need to think about this.
Using versions also frees us from a lot of the burden of maintaining packages. As soon as the library devs tag a new version it's available in the tool. We just need to make the initial recipe (or pull in a contribution from someone else).
This also makes switching between versions blazingly fast because we don't have to download anything, as long as the library was installed as an hg/git repo.
Version Numbering Schemes
Of course this won't be too easy -- I'm sure some libraries use esoteric version numbers as their tags. They could also have other tags that aren't version numbers. We can deal with this by allowing card files to define a
['list', 'of', 'tags'] --> parse_tags(tags) --> ['sorted', 'list', 'of', 'tags', 'representing', 'versions']
We can support the option to list versions of tarballs in the card files, but they should only be used as a last resort (or to bootstrap Mercurial). Cloning repositories is far more efficient the first time you want to update or switch versions.