Confirmed on 3.6 and 3.9.  The issue can be found in venv\__init__.py where the sys.prefix is used to determine the parent path of the python executable (near the bottom of the symlink_or_copy method at about line 190).  On the venv documentation page (https://docs.python.org/3/library/venv.html), it is noted that:

====
When a virtual environment is active (i.e., the virtual environment’s Python interpreter is running), the attributes sys.prefix and sys.exec_prefix point to the base directory of the virtual environment, whereas sys.base_prefix and sys.base_exec_prefix point to the non-virtual environment Python installation which was used to create the virtual environment. If a virtual environment is not active, then sys.prefix is the same as sys.base_prefix and sys.exec_prefix is the same as sys.base_exec_prefix (they all point to a non-virtual environment Python installation).
====

This code is called by lib\site-packages\build\env.py (venv.EnvBuilder...) which fails erroneously due to the divergent behavior of the sys.prefix as described in the documentation snippet above.

Recommended fix:  I'm not sure why that behavior diverges in the first place.  Ideally, either the build lib\venv\__init__.py should be updated to not rely on sys.prefix, or the sys.prefix behavior should be changed.

Additional Notes:
- I am seeing this issue on Windows 10
- The venv instance is within an Anaconda directory.
- The python -m build command I am running is from within a virtual environment
- I've listed file paths in relation to the library path within the same directory as the python executable for convenience.  Let me clarify, however, that there are multiple instances of the python lib folder: 1 global and 1 local copy.  The venv path is located in the global instance within the Anaconda path whereas the build script is using the virtual environment instance of python.

I don't inderstand what "discrepancy" you mean here. The documentation you quote explains the behaviour, and I don't see the problem.

If build is failing, why do you not think that is a bug in build? I can only see one call to venv.EnvBuilder in the code you mention and it looks correct. What error are you seeing?