I can describe what happens with test_sys_exit_in_exception_handler.py 

1. The 'boom' task raises an exception.
2. The task is not awaited, Future.__del__ calls the exception handler with 'Task exception was never retrieved' message.
3. The custom handler raises SystemExit.
4. SystemExit bubbles up and swallowed by __del__, the __del__ method cannot re-raise.

The question is: what is the behavior expected?
a) Now an exception raised by a custom exception handler is swallowed in this particular case (but is propagated if `loop.call_exception_handler()` is called from a function other than __del__).
b) Yuri suggested re-schedule an exception generated by `loop.call_exception_handler` by `loop.call_soon()`.  asyncio.Handle catches it and... calls `call_exception_handler()` with 'Exception in callback ...' message.  At the end, we have an endless recursion.
c) asyncio loop can call `loop.stop()` if an exception is raised by `loop.call_exception_handler()` from __del__.  I think this behavior is terrible: a subtle error can terminate asyncio program.
d) Assume that a custom exception handler should not raise an exception. Catch all exceptions in `call_exception_handler`, call sys.unraisablehook(), and suppress the exception.

I believe that d) is the best thing that we can do here.

I can prepare a fix if we agree on the solution.