My opinion:
CPython should require C, and that’s it. Platform-specific functionality and assumptions should power optional optimizations or exposing optional functionality (from sockets to profiler support).
Any hard requirement (e.g. threads/atomics, IEEE floats, stack growth assumptions) is best seen as an exception, and if we add a new one we should be extremely explicit about it. An unexpected new requirement should be treated as a serious bug.
In other words, the PEP 11 tiered platforms should define what we can test and debug, more than what we consider a bug. We should not over-fit CPython to the quirks of the tiered platforms.
(Of course, and as we learned here, something like “Linux” is not a single platform…)
FWIW, the SC approval for stack protection explicitly said it needs to be “portable”. It turns out that the feature is not portable. The issue is that we found this out too late. IMO, part of the issue is that the design was only revealed in the 3.14 RC phase, and hasn’t been discussed publicly as far as I know. Questions like “why not use mprotect?” now seem too late.
Anyway, the real question is what to do now.