python3.6-venv hijacks pip. what is a way to preve

I am chasing down an install failure. I have a fresh ubuntu xenial install. I have several different projects, each one involving dependencies requiring a different version of python, including a gnuradio project which seems to have the reasonable expectation that pip points to python2.7. Here is the first part of what I've run:

$ sudo apt-get update
$ sudo apt-get -yq upgrade
$ sudo apt-get -yq install python-pip
$ sudo pip install --upgrade pip
$ sudo apt-get install -yq python3-pip
$ sudo pip3 install --upgrade pip
$ sudo apt-get update
$ sudo apt-get -yq upgrade
$ sudo apt-get -yq install python-dev python3-dev
$ sudo apt-get install --fix-missing python-apt
$ sudo pip install numpy scipy matplotlib pybombs virtualenv
$ sudo apt-get -yq install build-essential libffi-dev libssl-dev python3-setuptools
$ sudo pip3 install --upgrade setuptools wheel
$ sudo pip3 install numpy scipy matplotlib virtualenv
$ sudo add-apt-repository ppa:deadsnakes/ppa
$ sudo apt-get install python3.6
$ sudo apt-get -yq install python3.6-venv python3.6-dev
$ sudo apt-get update
$ sudo apt-get upgrade

No complaints so far, when I check pip and pip3, they point where I want them to point:

$ pip -V
pip 9.0.1 from /usr/local/lib/python2.7/dist-packages (python 2.7)
$ pip3 --version
pip 9.0.1 from /usr/local/lib/python3.5/dist-packages (python 3.5)

Now I create a virtual environment for python3.6, enter it, in there pip points to python3.6 as expected, I install a few more packages, then exit the virtual environment and suddenly pip points to python3.5

$ mkdir projvenv
$ python3.6 -m venv /home/username/projvenv/
$ source /home/tom/vertexprojvenv/bin/activate
(projvenv) $ pip -V
pip 9.0.1 from /home/tom/projvenv/lib/python3.6/site-packages (python 3.6)
(projvenv) $ pip install numpy scipy matplotlib
(projvenv) $ deactivate
$ pip -V
pip 9.0.1 from /usr/local/lib/python3.5/dist-packages (python 3.5)

I have looked at this question which seems to address a purely anaconda issue, while the solution does not apply in my case. This discussion is more to the point, and points to a problem with pip. That particular bug is at least not quite what is going on for me since I am able to upgrade both pip pointing to python2.7 and pip3 pointing to python3.5, and the pip hijacking is not initiated by an upgrade. Any wisdom shed on this problem is much appreciated.

(edit)

$ which pip
/usr/local/bin/pip
$ head -1 `which pip`
#!/usr/bin/python3

Restore shebang line in /usr/local/bin/pip — make it #!/usr/bin/python2.

PS. Well, formally it's not a complete answer because the question is "How to prevent?" I don't know what program changed shebang line; but I doubt it was virtual environment.