mwh, my threading patch is extensive enough and has enough overlap that
I'm not intimidating by fixing this.  It's low on my list of priorities
though.

So far my tendency is to rip out multiple interpreters, as I haven't
seen what it wants to accomplish.  It's certainly *NOT* completely
isolated interpreters.

As for Py_Finalize, I see 4 purposes to calling it:
1) Finish any lingering bits of the program, such as __del__ methods or
weakref callbacks
2) Delete lingering references so refcount errors or memory leaks may be
more easily discovered
3) Prepare for Py_Initialize to be called again
4) Return the interpreter to a quiescent state such that python.so can
be safely unloaded, then reloaded and Py_Initialize called again

Of these, 3 and 4 are not done.  3 would be easy if Py_Finalize was a
no-op, but that'd undermine 1 and 2.  Given the optimistic
documentation, it's surprising how limited Py_Finalize's scope is.

I've seen some fleeting discussion of allowing extension modules to be
unloaded, which IMO requires returning them to a quiescent state.  Doing
that may lay the foundation for doing it to the entire interpreter.

Anyway, real use cases are critical here.  Although you may think you
want your plugins to unload python, the costs mean you should only do so
very rarely, enough that there's really no advantage to unloading it
(except at program shutdown, for purposes 1 and 2.)