Hi Petr, 

Thank you for your careful reading and encouragement.

 > The `ExceptionGroup` class is final, i.e., it cannot be subclassed.

What's the rationale for this?

ExceptionGroup.subgroup()/split() need to create new instances, and subclassing
would make that complicated if we want the split results to have the same type.

 > It is possible to catch the ExceptionGroup type with except, but not
with except* because the latter is ambiguous

What about `except *(TypeError, ExceptionGroup):`?

Good question. We should block that as well. 
 > Motivation: Errors in wrapper code

This use case sticks out a bit: it's the only one where ExceptionGroup
doesn't represent joining equivalent tasks.
Consider code similar to bpo-40857:

       with TemporaryDirectory() as tempdir:
           n = 1 / 0
   except ArithmeticError:
       # that error can be safely ignored!

Instead of a FileNotFoundError with ArithmeticError for context you'd
now get an ExceptionGroup. Neither is handled by `except
ArithmeticError`. Where is the win?

I agree, if TemporaryDirectory() were ever to adopt ExceptionGroups then it will probably
be through a new API (like an opt-in parameter) to avoid breaking current code. Users of 
such a TemporaryDirectory would need to wrap the calls with try-except* (see the example
in my previous reply to Steve).
 > Motivation: Multiple failures when retrying an operation

This is somewhat similar to the TemporaryDirectory, except there's no
`with` block that feels like it should be "transparent" w.r.t. user errors.
If I currently have:

     except (Timeout, NetworkNotConnected):
         # that's OK, let's try later

what should happen after Python 3.10? Apart from adding a new function,
I can see two possible changes:
- create_connection() starts always raising ExceptionGroup on error,
breaking backwards compatibility in the error case
- create_connection() starts only raising ExceptionGroup only for 2+
errors, breaking backwards compatibility in the 2+ errors case 

Both look like heisenbug magnets. IMO, the second one is worse; "code
which is now *potentially* raising ExceptionGroup" (as mentioned in the
Backwards Compatibility section; emphasis mine) should be discouraged.

Arguably, this here is a problem with the create_connection function:
the PEP adds a better way how it could have been designed, and that is
virtuous. Still, having it in Motivation might be misleading.

I agree. Raising ExceptionGroups is an API breaking change, for any library. 
No function should just start raising ExceptionGroups.

 > long term plan to replace `except` by `catch`

Whoa! Is that a real plan?

In the rejected ideas section, anything goes!