Since reload re-uses the existing namespace, having two names is less messy when they're just aliases for the same module object (it still has all the usual cache validity problems of any reload operation, but it doesn't have the extra challenges of two different module objects derived from the same source code).

As such, with -m, adding:

    import __main__
    sys.modules[__main__.__spec__.name] = __main__

is sufficient to get this working again, and will work for any of the PEP 451 based versions (i.e. 3.4+). (I'm open to an RFE to get runpy to do this by default in 3.7+ - it's an idea that has come up several times, and I think it will ultimately be less surprising than the current behaviour of allowing two entirely distinct copies of the module to be loaded)

The direct execution case is a bit different, as that's genuinely missing a __spec__ entry, and needs to be told how to reload itself:

    import __main__
    main_file = __main__.__file__
    main_name = os.path.splitext(os.path.basename(main_file))[0]
    __main__.__spec__ = importlib.util.spec_from_file_location(main_name, main_file)
    sys.modules[__main__.__spec__.name] = __main__

The two cases can be distinguished at runtime by whether or not __main__.__spec__ was already set.

Since this isn't really something we encourage people to do in general, but does remain possible for frameworks that want to support live reloading of __main__, I'm OK with requiring that extra framework-provided scaffolding in 3.4+.