Take for example the case that you have to juggle with several venvs and mix them together. This has happened to me in the past in very legitimate cases. You have to add those venvs to the path yourself. I am not talking about having a shell where you do your work but some other automated tasks.

Or jedi (http://jedi.jedidjah.ch/) which has become a popular autocompletion third party tool that supports venvs. You pass it the base directories and it adds their site-packages to the appropriate places. Naturally it has to know if those are under lib or lib64.

Just to name two examples. I guess there are more tools out there which have to juggle with venvs and would stumble upon this inconsistency in comparison with virtualenv. Both are naturally fixable on the user side here but since virtualenv provided those symlinks since quite a while and since IMHO venv should stay as compatible with it as possible, it would be nice if venv provided those too.

Besides all of that, creating a "lib"-dir during the venv creation while for all later installations via pip "lib64" is used (which wasn't created initially), sounds like a bug all in itself. ;-)

If you want, I could have a look and come up with a patch, if you would be willing to consider this "feature" (adding a lib64 to lib symlink).