>when particular instances of "catch this exception, but not these ones" become common, we tend to *change the standard exception hierarchy* to eliminate them (e.g. StopIteration, KeyboardError, GeneratorExit no longer inheriting from Exception).

But my patch does not change that behaviour.
We already have "catch this exception, but not these ones". It's called contextlib.suppress.
I'm not adding this behaviour to the library/language.
This patch just improves contextlib.suppress in the way that we can now easily remove exceptions from the suppress-set.

>So if you have new cases where that's happening frequently for you 

Ok, let me explain the real world scenario that I have here.
Imagine some application that does something over the network and an exception occurs. We catch that and decide that the program must die. However before doing so we need to send stuff over the network to cleanly tear down things. This is done on a best-effort basis. So we try to send these messages, but we silently ignore _all_ failures. What would we do anyway? We are exiting already.

And that's what I do. Wrap these actions in helpers that ignore all exceptions, except for SyntaxError and NameError and such, so that I can still see programming errors in the source code.
So I would do 'with suppress(Exception, unless=(SyntaxError, ...)'.

I do think that tearing down stuff and ignoring every exception really is a common thing to do. See __del__ for example. There's a reason we must make sure to ignore all exceptions before we return from __del__.
We could actually use suppress with unless for this.

If we try to handle exceptions in a tear-down situation instead, we will end in an infinite loop most of the time.

But suppress.unless is useful for other things, too.
It's a way to say: I want to ignore this set of errors, except this/these single ones from the set.
This patch adds the 'except' part of this sentence to contextlib.suppress.