diff --git a/peps/pep-0765.rst b/peps/pep-0765.rst
index f2036b0b1a8..c9418f68bb9 100644
--- a/peps/pep-0765.rst
+++ b/peps/pep-0765.rst
@@ -154,6 +154,48 @@ that their code needs to change. The `empirical evidence
 shows that the changes necessary are typically quite
 straightforward.
 
+Rejected Ideas
+==============
+
+Emit `SyntaxError` in CPython
+-----------------------------
+
+:pep:`601` proposed that CPython would emit `SyntaxWarning` for a couple of
+releases and `SyntaxError` afterwards. We are leaving it open whether, and
+when, this will become a `SyntaxError` in CPython, because we believe that a
+`SyntaxWarning` would give most of the benefit with less risk.
+
+Change Semantics
+----------------
+
+It `was suggested <https://discuss.python.org/t/pep-765-disallow-return-break-continue-that-exit-a-finally-block/71348/32>`__
+to change the semantics of control flow instruction in finally such that an
+in-flight exception takes precedence over them.  In other words, a `return`,
+`break` or `continue` would be permitted, and would exit the `finally` block,
+but the exception would still be raised.
+
+This was rejected for two reasons. First, it would change the semantics of
+working code in a way that can be hard to debug: a `finally` that was written
+with the intention of swallowing all exceptions (correctly using the documented
+semantics) would now allow the exception to propagate on. This may happen only
+in rare edge cases at runtime, and is not guaranteed to be detected in testing.
+Even if the code is wrong, and has an exception swallowing bug, it could be
+hard for users to understand why a program started raising exceptions in 3.14,
+while it did not in 3.13.
+In contrast, a `SyntaxError` is likely to be seen during testing, it would
+point to the precise location of the problem in the code, and it would not
+prevent the program from running.
+
+The second objection was about the proposed semantics. The motivation for
+allowing control flow statements is not that this would be useful, but rather
+the desire for orthogonality of feature (which, as we mentioned in the
+introduction, is already violated in the case of `except*` clauses). However,
+the proposed semantics are complicated because they suggest that `return`,
+`break` and `continue` behave as they normally when finally is called without
+an in-flight exception, but turn into something like a bare `raise` when there
+is one. It is hard to claim that the features are orthogonal if the presence
+of one changes the semantics of the other.
+
 Copyright
 =========