To summarise the discussion so far:

The arguments in favour of changing exception matching to match on virtual base classes are:

1. It is confusing that it doesn't follow issubclass semantics.
2. Two use cases were presented as practical motivation.
   - one in msg135521, which can be solved with the pattern in msg200418
   - one in msg200829, which is typically done with
     except:
         if condition:
              handle
         raise

The arguments against the change are
1. safety - calling python code from the exception propagation code
2. possible performance impact


I am not too worried about the performance of exception handling. I am also not impressed by the use cases.

For me it's mostly between the safety issue and the aesthetic language consistency issue. 

The code path from when a RAISE opcode executes and until control passes to an except clause, is a very sensitive one and I have a lot of sympathy to the position that we should just change the documentation to say that matching is on non-virtual base classes.  It is much easier to implement this feature than to predict how it would behave in all cases.

If we do decide to implement this, then I don't think the patch is the way we should do it. If the IsSubclass call fails, this should result in a "goto error", like when the match type is invalid: 
https://github.com/python/cpython/blob/7ba1cc8049fbcb94ac039ab02522f78177130588/Python/ceval.c#L3831

This means that the failure to determine whether the exception is a match is the dominant error, rather than something we print to the ether via the unraisablehook and interpret as non-match.