Regarding your 3 points:

> a) Py_Finalize cannot be used reliably

Note that unloading extension modules is not the only thing that Py_Finalize isn't doing that it probably should be.  I expect that you would find a number of memory leaks and potentially cases that crash the process when calling Py_Initialize() after Py_Finalize().

As bpo-401713 indicates, calling Py_Initialize/Py_Finalize multiple times isn't a well supported pattern.  The docs indicate likewise (see https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx).  That said, I'm sure everyone agrees that it *should* work and that we should fix issues there when we can.  It's mostly a matter of finding folks motivated enough to work on it. :)

> b) There is no possibility to reliably reset the python interpreter otherwise

At the level of the interpreter (main or otherwise), the C-API doesn't really provide anything like that, though I suppose it could.  However, it's mostly simpler to just make a new interpreter.  So I doubt we'd introduce an explicit concept of resetting an interpreter.  What would be the advantage?

At the level of the *runtime* the C-API likewise doesn't offer anything for reset, other than what you've already tried.  It would really help to understand why resetting is needed.

>  (because the sub-interpreters are also not working reliably,
> which is stated in the documentation)

This is something I'm actively working on, including improving isolation between interpreters (minimizing global state) and improving the extension module experience when using subinterpreters.  The latter is tricky, particularly with extension modules that use libraries that have their own C globals.

Note that isolation between interpreters will never be perfect.  If you need perfect isolation then use multiple processes.  All interpreters in the same process will always share the runtime state, as well as process-wide data.

FWIW, even if we were to completely isolate the Python runtime, allowing more than one runtime in a process, the runtimes would still share the process-wide data.

> c) manually reloading changed modules via importlib.reload is not a
> feasible solution

Yeah, while I suppose it could work for some extensions, I expect it would not work for many.