> I'm inclined to say YAGNI, and we simply leave "/usr/bin/env python3" undefined. 

I can't say I'm really happy with this answer. Fact is, 
1) you almost always have to work from within a virtual env these days, 
2) you really want to have meaningful shebangs (ie, version-specific) in your scripts because, well, 2017 and the world is still split between py2 and py3, 
3) the py.exe launcher is the new shiny thing and we all just want to use it.

So, it *could* annoy some people to find out that py.exe just can't handle both venvs and shebangs in a meaningful way, and you must give up on either venvs, or shebangs, or py.exe. 

As far as I know (3.6.0 and 2.7.13), you have 3 ways to invoke a script:

1) "version-specific" launcher (eg "py -3 foo.py"): this will always pick the system interpreter, never abides neither venvs nor shebangs. A perfectly defined, utterly useless behavior. 

2) invoke interpreter (eg "python foo.py", the good old way): this will always be venvs-complaint, will never parse shebangs. And yet at the moment, it's probably your best option *when* inside a venv - and the worst when outside, of course. 

3) "version-agnostic" launcher (eg "py foo.py"). Outside a venv, this will always abide version-specific shebangs (ie, "#!python3"); the only quirk being that when facing a generic shebang instead, it will pick Python 2 (because, 2017 and Linux...). Oh well, I can live with that. 
But when you are inside a venv, then
- if it finds a "not-env" shebang (ie "python" or "/usr/bin/python"), then it will NOT abide the venv - frustrating, yet correct I suppose;
- if it finds any kind of version-specific shebang (EVEN a "env"-type of shebang!), then again it will follow the shebang but NOT the venv, and will pick up the system interpreter. That, even when you are inside a venv that perfectly matches the shebang prescription. 

Now, this can be very frustrating because a useless "/usr/bin/env python" shebang triggers the correct behavior both inside and outside a venv, BUT a much more useful "usr/bin/env python3" will fail even if we are inside a matching venv. 

I feel that all it needs to be perfect is some kind of behavior like this: dear py.exe, 
- when you are invoked in a version-agnostic way, and 
- when you find an "env"-and-version-specific shebang in the script, 
then please, 
- just look at my %path% before doing anything else. It could be that the first interpreter you find there will just match the requirement from the shebang (that is, because on occasion I just know what I'm doing, and I've just activated a matching venv, you see). If so, just give me that Python and I will be ok; 
- otherwise, my bad: feel free to resume any other search strategy you find appropriate, and I will humbly accept whatever interpreter you may fetch, even a php one. 

I think this would be just reasonable enough. What I'm missing here?