PEP-654: add mention of the 'Flat EG' proposal to the rejected ideas …

…section (GH-2104)

pep-0654.rst

@@ -1183,7 +1183,8 @@ Furthermore, as we explained in the `Handling Exception Groups`_ section, we
 find it unlikely that iteration over leaf exceptions will have many use cases.
 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.
+be useful in practice, we can in the future add that utility to the standard
+library or even make exception groups iterable.
 
 Make ``ExceptionGroup`` Extend ``BaseException``
 ------------------------------------------------
@@ -1255,10 +1256,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.
 
+The idea of making ``except`` iterate over the leaf exceptions of an exception
+group is at the heart of an `alternative proposal to this PEP by Nathaniel J. Smith
+<https://discuss.python.org/t/flat-exception-groups-alternative-to-pep-654/10433>`_,
+and the discussion about that proposal further elaborates on the pitfalls of
+changing ``except`` semantics in a mature language like Python, as well as
+deviating from the semantics that parallel constructs have in other languages.
+
 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
+of matching type from the group in order to handle it (while discarding all
+the other exceptions in the group). 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