(Note that PathFinder.invalidate_caches() loops over sys.path_importer_cache and invalidates the cache of each path entry finder therein.  What you're suggesting is clearing sys.path_importer_cache after the loop finishes.)

Hmm.  The distinction is between clearing the cache of each finder and clearing the caches in the import machinery, sort of.  sys.path_importer_cache effectively belongs to PathFinder, just like sys.path_hooks.  I expect they are part of sys only as a historical artifact (i.e. pre-importlib).  So I'd say there isn't any conceptual problem in that regard.

The point of importlib.invalidate_caches() is to allow finders to pick up out-of-band events.  In the case of sys.path_importer_cache, it would allow new entries in sys.path_hooks to have a shot and old entries to have another chance.  That seems reasonable.

The only caveat I see is that sys.path_importer_cache is not an "internal" cache (as the importlib.invalidate_caches() docs refer to them).  Furthermore, it has some established semantics attached:

  * a path hook will only be called once for a path entry (entries in the cache are fixed in place once added)
  * None is a sentinel for not-found

Consequently,someone may inject None into the cache to prevent finding a spec/loader. With this chance, calls to importlib.invalidate_caches() could cause them problems.  In this regard there may be a backward-compatibility issue.

Other than that, I consider clearing sys.path_importer_cache in PathFinder.invalidate_caches() to be a reasonable change.