Consider the following situation:

System python2.7
Project 1 has repo1 with sha1 and hook1 configured with python3.4
Project 2 has repo1 with sha1 and hook1 configured with default python version (system python2.7)

In ~/.pre-commit/ if project 1's hooks are run first, the repo created will have a python3.4 interpreter. If project 2 goes to run the hooks, they'll continue to use the interpreter intended for project1, not the interpreter specified in project2.

I think the best way to approach this is to include the interpreter version in the virtualenv directory. This'll allow (in this example) a venv-python3.4 and a venv-default to live side-by-side and not clobber each other.