Thanks for the ping.

The actual code changes look OK to me for the initially proposed design, which means the main missing piece would be documentation updates (both to the docstrings and to runpy module reference).

However, thinking about how those docs might be written, I'm starting to think the specific proposed design would be inherently confusing for folks that aren't already familiar with runpy's internals, and it might be better to use a callback API with a few predefined helper functions.

That is, suppose the new parameter was a callback accepting the following parameters:

* "module" - the module about to be executed
* "argv" - sys.argv prior to module execution

And then we have 3 predefined callbacks/callback factories in runpy:

def keep_argv(module, argv):
    return argv

def set_argv0(module, argv):
    return module.__file__ + argv[1:]

def set_argv(argv, *, implicit_argv0=True):
    argv_override = list(argv)
    if implicit_argv0:
        def _set_argv(module, original_argv):
            return [module.__file__] + argv_override
    else:
        def _set_argv(module, original_argv):
            return argv_override
    return _set_argv

Then the three scenarios in your original post would look like:

    runpy.run_module(mod_name, argv=set_argv0)
    runpy.run_module(mod_name, argv=keep_argv)
    runpy.run_module(mod_name, argv=set_argv(iterable))

(and similarly for run_path)

"argv=None" would be the default, and equivalent to specifying "argv=set_argv0"

"argv=set_argv(iterable, implicit_argv0=False)" would allow even more precise control of the argv settings seen by the running module.

Future and/or custom variations would be straightforward, since we're just passing in a callable.

The documentation benefit is that the "argv" parameter docs can just describe the callback signature and the use of "set_argv0" as the default, with the details of the individual behaviours moving to the definitions of the corresponding functions.