The statement that "this work is very carefully designed not to break multithreaded code" is difficult to reconcile with some of the ways it potentially breaks multithreaded code that are explicitly called out down in the "compatibility" section.

In particular, the design document's observation that "some C API extensions need modifications to protect global data structures that were previously protected by the GIL" serves as a direct confirmation that this change was not able to avoid breaking at least some multithreaded code that relies on the GIL to provide thread safety.

I meant w/r/t pure Python code, which the comment I replied to seemed to be implying.

Yes, C extensions that count on the GIL for handling their own internal locking will obviously need updates.