> Is there any reason to not resolve the base executable on creation and 
> make it relative to that? So the second pyvenv.cfg would have the same 
> home directory as the first?

I was trying to avoid changing the existing behavior of `home` from how it works in 3.6. Your solution will introduce a (probably minor) change, which may be for the best anyway. The computed argv0_path gets added to sys.path, which in the normal case is the installation directory, but it gets overridden by `home`. In 3.6, in the nested-create case, the argv0_path is the creating environment's Scripts directory. For example: 

    C:\>type C:\Temp\test\env36_2\pyvenv.cfg
    home = C:\Temp\Test\env36_1\scripts
    include-system-site-packages = false
    version = 3.6.4

    C:\>C:\Temp\test\env36_2\Scripts\python.exe -S
    Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40)
    [MSC v.1900 64 bit (AMD64)] on win32
    >>> import sys
    >>> print(*sys.path, sep='\n')

    C:\Temp\test\env36_2\Scripts\python36.zip
    C:\Program Files\Python36\Lib\
    C:\Program Files\Python36\DLLs\
    C:\Temp\Test\env36_1\scripts

I don't know why we add argv0_path to sys.path. If it's meant to be the directory of the (not necessarily real) executable, then the last path in the above example should be "C:\Temp\Test\env36_2\Scripts" instead of "env36_1\Scripts". If the argv0_path is meant to be the installation directory, as part of the standard library, then it should be "C:\Program Files\Python36". PR 11745 will make it consistently the latter for all virtual environments.