... I've started to call it the Logajan paradox: he wants his cake (zero backwards incompatibilities) and eat it too (releases with new features). It can't be done.
I don't believe I ever heard James ask for a new feature, although he has allowed that new features might be OK provided that the Python version introducing them continues to run all older Python scripts without change.
Rubin's view is more complicated, and I'm not sure it's been coherently expressed.
Note that Logajan's view is hard to distinguish from what most ANSI/ISO language standard committees accept as their burden most of the time: no breakage of programs that conformed under the last standard, period. That's why, e.g., the C99 bool type was added via a pile of macro tricks, and requires #include'ing a new header file in any program that wants to use it as intended (the actual name of the new type is "_Bool", which is of a syntactic form C89 reserved to the language implementation; indeed, all the symbols Python uses internally of the form _Pxyz are forbidden to us by the std (Python's implementation is non-conforming all over the place); C99 couldn't add "bool" as a new keyword, but they could add _Bool, and then "#define bool _Bool" in a new standard header file; that can't break any existing code, because no existing code could possibly have #include'd the previously non-existent <stdbool.h>; note too that older header files (like
<stdio.h>) are forbidden from #include'ing stdbool.h on their own -- or, if they do, they have to hide all evidence of that from users).
The ANSI/ISO committees pour person-decades into dreaming up ways to break nothing. It's not a crazy view on its own, but it's extremely expensive to do things that way (I've been on one ANSI committee, and worked closely with two others in previous lives -- it's excruciatingly slow going, and costs participants millions of dollars before it's over). It also requires extreme care in defining what "a conforming program" is, exactly.