I agree that this is something we need to address in 3.5.  Adding this to 3.4 won't be an option since it would require a new feature.  However, Loader.load_module() is only deprecated (and won't be removed in 3.X), so the current approach will still work until we provide a new approach in 3.5.  The only gap is that now it is possible (even if very unlikely) that in 3.4 you would run into a loader that does not implement load_module(), which would obviously break direct calls to the method. :(

For 3.4 such direct calls in the stdlib to loader.load_module() were replaced with this (mostly):

  spec = importlib.util.spec_from_loader(name, loader)
  # or importlib.util.spec_from_file_location(...)
  methods = _SpecMethods(spec)
  mod = methods.load()

As you already noted, this relies on a current implementation detail of importlib._bootstrap.  We'd rather not encourage use of such private API so providing a simple replacement makes sense.

Futhermore, for 3.5 (in the "soon" timeframe) I'm planning on working on improving the import system abstractions*.  My expectation is that part of that will be exposing most or all of the functionality of _SpecMethods directly.  At the same time I don't want that API to be a distraction.  I think accomplishing both is doable.

So you shouldn't need to worry about create() or anything else.

* Suggestions welcome. :)  You can email me directly (ericsnowcurrently@gmail.com).