At this point, here are the open questions I'm seeing:

+ The editing-stdlib-.py-files problem:
   * use a command-line flag to opt-out of frozen modules?
   * use a build flag to opt out (e.g. a configure flag or a new Py_NO_FROZEN or even Py_DEBUG)?
   * ignore frozen modules if it's a dev build?
   * (note: importlib._bootstrap and importlib._bootstrap_external must always be frozen, regardless of a flag)
   * accommodate users of an installed Python that sometimes edit stdlib modules while debugging code?
   * always emit a warning if a frozen module is ignored (in favor of the source module)?

+ Compatibility:
   * set __file__ (and __path__) on frozen modules?
   * store the hash of the source file for frozen modules (in the frozen .h files)?
   * support more of the FileLoader API on the frozen loader?

+ Penalty for too many frozen modules:
   * should we only freeze the UTF-8 encoding?
   * should we use something other than linear search for looking up frozen modules?

FWIW, I think the ideal mechanism for a dev build will be to opt in to using frozen modules (instead of the source modules).  Otherwise it is too easy for the unaware contributor to waste substantial time figuring out why their changes are not getting used.

Consequently, here's my order of preference for ignoring frozen modules:

1. use Py_DEBUG as an opt-out flag
   (if we think contributors are editing stdlib modules on a build without Py_DEBUG then that isn't good enough)
2. automatically skip frozen modules if it's a dev build, with an explicit configure flag to opt in to frozen modules