I'm not comfortable with PR 28525 which always hang threads which attempt to acquire the GIL after Python exited.
I would prefer to keep the current behavior by default, but give the ability to applications embedding Python to decide what to do.
With my Py_SetThreadExitCallback(func) idea, PyThread_exit_thread() would call func() and then pthread_exit(0). Applications can hang threads, log a message, call abort(), or whatever else.
I'm not comfortable with writing a portable function to "hang a thread". For example, I don't understand why PR 28525 processes Windows messages on hang threads.
Well, it's a complex problem :-(