I think this is causing a regression for code that explicitly desires the ThreadPoolExecutor to go away abruptly when all other non-daemon threads complete (by choosing not to use a with statement, and if shutdown is called, calling it with wait=False, or even with those conditions, by creating it from a daemon thread of its own).

It doesn't seem like it's necessary, since the motivation was "subinterpreters forbid daemon threads" and the same release that contained this change (3.9.0alpha6) also contained #40234's change that backed out the change that forbade spawning daemon threads in subinterpreters (because they now support them by default). If the conflicts with some uses of subinterpreters that make it necessary to use non-daemon threads, could that be made a configurable option (ideally defaulting to the pre-3.9 choice to use daemon threads)?