There should be a boolean flag that enables/disables cached copies of .py files from Lib/.  You should be able to turn it off with either an environment variable or a command-line option, and when it's off it skips all the internal cached stuff and uses the normal .py / .pyc machinery.

With that in place, it'd be great to pre-cache all the .py files automatically read in at startup.

As for changes to the build process: the most analogous thing we have is probably Argument Clinic.  For what it's worth, Clinic hasn't been very well integrated into the CPython build process.  There's a pseudotarget that runs it for you in the Makefile, but it's only ever run manually, and I'm not sure there's *any* build automation for Windows developers.  AFAIK it hasn't really been a problem.  But then I'm not sure this is a very good analogy--the workflow for making Clinic changes is very different from people hacking on Lib/*.py.

It might be sensible to add a mechanism that checks whether or not the pre-cached modules are current.  Store a hash for each cached module and check that they all match.  This could then be part of the release process, run from a GitHub hook, etc.