[Windows RT Development and Hacking] nbetcher:
(The following post is long, and arguably overly verbose. This is because I want to document my work for others, and to talk through what I've found so far in order to digest it better.)

I think the main reason you may have encountered issues is because of the integrated duality of the host-versus-target toolchain. When we develop on x86 or x64, generally our target is one or the other, even if the OS is different, so we don't need to concern ourselves much with the "host" portion of the toolchain. That is because the OS handles the abstraction between the 32-bit vs 64-bit aspects of the toolchain's requirements.

However, in the case of ARM, it is a completely different target and shares no common ground with the host. As such, you have to have a toolchain that is compiled with x86/x64 host support, but as a target of ARM32/64. The result is a bit more complicated.

I think that is the reason it is difficult for many to conceptualize the solution to the problem. Looking through the build configuration files last night (for only a brief time), I saw this comment in vs_toolchain.py (the main offender):

Sets up os.environ to use the depot_tools VS toolchain with gyp, and
returns the location of the VC runtime DLLs so they can be copied into
the output directory after gyp generation.
Return value is [x64path, x86path, 'Arm64Unused'] or None. arm64path is
generated separately because there are multiple folders for the arm64 VC
runtime.

Namely this:

arm64path is
generated separately because there are multiple folders for the arm64 VC
runtime.

In this particular function ( SetEnvironmentAndGetRuntimeDllDirs() ), 'Arm64Unused' is returned for the target object of arm64_runtime (in CopyDlls() ), which is ultimately called from the main() function. Call Stack (for visualization):

vs_toolchain.py invoked ->

main() returns command, toolchain dir, and Toolchain DLLs for copy ->

CopyDlls() returns the toolchain DLLs for copy ->

SetEnvironmentAndGetRuntimeDllDirs() returns the specific directories where those DLLs may be found -> returns 'Arm64Unused' for ARM64.

Obviously 'Arm64Unused' is not a valid absolute path. At this point I'm attempting to track down how that value is digested. With ARM32 handling added and 'Arm32Unused' values being passed (among several other blocks of code), when calling 'gn args .' (in my build directory) I am getting these errors:

C:\src\src\build>gn args .
Waiting for editor on "C:\src\src\build\args.gn"...

Generating files...
Traceback (most recent call last):
File "C:/src/src/build/toolchain/win/setup_toolchain.py", line 315, in <module>
main()
File "C:/src/src/build/toolchain/win/setup_toolchain.py", line 273, in main
env = _LoadToolchainEnv(cpu, toolchain_root, win_sdk_path, target_store)
File "C:/src/src/build/toolchain/win/setup_toolchain.py", line 188, in _LoadToolchainEnv
variables = _LoadEnvFromBat(args)
File "C:/src/src/build/toolchain/win/setup_toolchain.py", line 99, in _LoadEnvFromBat
raise Exception('"%s" failed with error %d' % (args, popen.returncode))
Exception: "['C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Auxiliary\\Build\\vcvarsall.bat', 'amd64_x86', '10.0.20348.0', '&&', 'set']" failed with error 255
ERROR at //build/toolchain/win/toolchain.gni:500:24: Script returned non-zero exit code.
win_toolchain_data = exec_script("//build/toolchain/win/setup_toolchain.py",
^----------
Current dir: C:/src/src/build/
Command: C:/src/depot_tools/bootstrap-2@3_8_10_chromium_23_bin/python3/bin/python3.exe C:/src/src/build/toolchain/win/setup_toolchain.py "C:\Program Files\Microsoft Visual Studio\2022\Community" "C:\Program Files (x86)\Windows Kits\10" "C:\WINDOWS\System32;C:\WINDOWS\SysWOW64;Arm64Unused;Arm32Unused" win x86 environment.x86
Returned 1.
See //build/toolchain/win/BUILD.gn:34:3: whence it was called.
win_toolchains("x86") {
^----------------------
See //BUILD.gn:83:1: which caused the file to be included.
group("gn_all") {
^----------------

You'll note that

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat is being called with 'amd64_x86' (which is in the form of host_target), which I seriously doubt is correct. It should likely be 'amd64_arm' or 'x64_arm'.

It took me significantly longer to write this post than to get to the above stopping point, but now... on with figuring it out...