As requested, I've attached a small test script called shadow.py.  Steps to reproduce:

1) pyvenv.py bugtest
2) copy the attached shadow.py script to bugtest and bugtest\scripts
3) cd bugtest
4) run shadow.py (first entry in sys.path is refers to bugtest directory per Python docs; finds the systems's pydoc module)
5) run bugtest\shadow.py (first entry in sys.path refers to bugtest\scripts directory per Python docs; finds the bugtest\scripts pydoc module instead of the system's pydoc module)

According to the Python documentation (http://docs.python.org/3/library/sys.html#sys.path):

"As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter. If the script directory is not available (e.g. if the interpreter is invoked interactively or if the script is read from standard input), path[0] is the empty string, which directs Python to search modules in the current directory first. Notice that the script directory is inserted before the entries inserted as a result of PYTHONPATH."

Maybe I'm missing something here, but isn't this problem caused by the fact that Python initializes sys.path[0] to contain the directory of the executing script and that having pydoc.py in that same directory (i.e. the venv's scripts directory) shadows the system's pydoc.py module?  On Linux, I didn't have this problem, because the pydoc script doesn't have the .py extension.  However, if you rename the pydoc script on Linux to pydoc.py, the same problem occurs.

I don't think a pydoc.py (or any other .py file which shadows a system module) can exist in the venv scripts (or bin) directory without shadowing/breaking the system provided module.  Maybe a pydoc.exe or pydoc.bat file is needed on Windows?  Another option would be to rename the pydoc.py file to something like pydocs.py, but that would be incompatible with other platforms and the existing documentation.