The launcher could be extended to support additional suffixes in the version string. Currently -32 is supported after the minor version number (e.g. 3.6-32), and (per a recent update) the latest version of the launcher will also support -64, with and without specifying the minor version number. This could be extended to support specifying an [o]fficial / [s]ource and [r]elease / [d]ebug build. A debug build wouldn't be separately registered on the system since it coexists with the release build. Instead, "d" would force the launcher to look for python_d.exe instead of python.exe. A default search would prefer an official build over a source build and a release build over a debug build. The point of supporting "o" and "r" suffixes is to force an error if an official/release build isn't available, rather than defaulting to a source/debug build. 

Under the hood, the INSTALLED_PYTHON struct would be extended with source_build and debug_build boolean values in addition to the bits value (which is an int but may as well be boolean). So there are up to 8 possibilities for every minor version number. MAX_INSTALLED_PYTHONS shouldn't have to be increased from 100. 

For example, `py -3-32d` would look for the highest 3.x 32-bit debug build and prefer an official build over a source build. `py -3-32od` would narrow the search to only official builds. `py -3-32sd` would instead narrow it to only source builds. In the latter case, the registry key would be named like "3.7-32s" to distinguish it from an official install. A build process with admin privileges would register the build in HKLM (taking care to create a "-32" key using KEY_WOW64_32KEY). Otherwise use HKCU.

For convenience, build.bat could set PY_PYTHON after a successful build, to make the current source build the default for the command-line and virtual shebangs, e.g. `set PY_PYTHON=3.7sd` for a registered 64-bit debug build. This would have to be executed after an endlocal statement, since it does most of its work in a setlocal block.