PEP-654: add to the rejected ideas section, following public discussion

pep-0654.rst

@@ -1110,6 +1110,39 @@ We did, however, provide there the code for a traversal algorithm that
 correctly constructs each leaf exceptions' metadata. If it does turn out to
 be useful in practice, we can add that utility to the standard library.
 
+Make ``ExceptionGroup`` Extend ``BaseException``
+------------------------------------------------
+
+We considered making ``ExceptionGroup`` subclass only ``BaseException``,
+and not ``Exception``. The rationale of this was that we expect exception
+groups to be used in a deliberate manner where they are needed, and raised
+only by APIs that are specifically designed and documented to do so. In
+this context, an ``ExceptionGroup`` escaping from an API that is not
+intended to raise one is a bug, and we wanted to give it "fatal error"
+status so that ``except Exception`` will not inadvertently swallow it.
+This would have been consistent with the way ``except T:`` does not catch
+exception groups that contain ``T`` for all other types, and would help
+contain ``ExceptionGroups`` to the parts of the program in which they are
+supposed to appear. However, it was clear from the public discussion that
+``T=Exception`` is a special case, and there are developers who feel strongly
+that ``except Exception:`` should catch "almost everything", including
+exception groups. This is why we decided to make ``ExceptionGroup`` a
+subclass of ``Exception``.
+
+Make it Impossible to Wrap ``BaseExceptions`` in an Exception Group
+-------------------------------------------------------------------
+
+A consequence of the decision to make ``ExceptionGroup`` extend
+``Exception`` is that ``ExceptionGroup`` should not wrap ``BaseExceptions``
+like ``KeyboardInterrupt``, as they are not currently caught by
+``except Exception:``. We considered the option of simply making it
+impossible to wrap ``BaseExceptions``, but eventually decided to make
+it possible through the ``BaseExceptionGroup`` type, which extends
+``BaseException`` rather than ``Exception``.  Making this possible
+adds flexibility to the language and leaves it for the programmer to
+weigh the benefit of wrapping ``BaseExceptions`` rather than propagating
+them in their naked form while discarding any other exceptions.
+
 Traceback Representation
 ------------------------
 
@@ -1147,6 +1180,18 @@ clauses with the knowledge that they are only executed once. If there is
 a non-idempotent operation there, such as releasing a resource, the
 repetition could be harmful.
 
+Another option that came up in the public discussion was to add ``except*``,
+but also make ``except`` treat ``ExceptionGroups`` as a special case.
+``except`` would then do something along the lines of extracting one exception
+of matching type from the group in order to handle it. The motivation behind
+these suggestions was to make the adoption of exception groups safer, in that
+``except T`` catches ``Ts`` that are wrapped in exception groups. We decided
+that such an approach adds considerable complexity to the semantics of the
+language without making it more powerful. Even if it would make the adoption
+of exception groups slightly easier (which is not at all obvious), these are
+not the semantics we would like to have in the long term.
+
+
 A New ``except`` Alternative
 ----------------------------