First off, thanks for looking into this and reaching out to possibly affected projects.
I’d like to add a small detail that I don’t think was well captured in the analysis there.
One case which was addressed with a code change would have been working as intended if not for unresolved differences in the ProactorEventLoop in asyncio (namely, not having a way to add signal handlers to the event loop, nor a default signal handler which would gracefully shutdown an event loop on windows, it’s handled by repeatedly catching and reraising KeyboardInterrupt in various places)
The intent in this case remained to suppress all non-shutdown exceptions, and if asyncio had implemented signal handling as part of the normal asyncio event loop runners in a uniform manner, no code change would have happened for this.
In the same repository, there was a false positive involving threading (explicitly in a threading.Thread subclass), as catching KeyboardInterrupt or SystemExit wouldn’t be a concern, and the intent was to silence all exceptions that could occur as any exceptions that would happen here would not be something a user of the library would be able to handle.
It seems to me that the danger here is not returning in finally, but that reasonable expectations about where certain exceptions as interrupts can be raised aren’t accurate, and that fixing this would help a lot more code than changing the nature of swallowing exceptions in finally which is rarely used.