As someone else noted, few of the ideas originating on typing-sig are for syntax changes. 

One might argue that some are "abuse of notation."  Generally they are of the sort "let's support indexing or bitwise operators on some more types" or let's let more builtin things act as types in annotations.

Whether good or bad, that's not syntax 

The last time typing-sig proposed a syntax change was PEP 677 which was rejected. Finn notes several non-syntax changes that were accepted from python-ideas. Those are new parameters or methods for builtins, again not syntax. He notes another which is "add a library to stdlib", again not syntax.

Most ideas SHOULD get rejected, simply because most are poorly or partially thought through. But even many that are *reasonable* in and of themselves are not worth  adding the complication. I'm sure if Guido had put `for x in stuff if cond` I'd probably use it most days.

But tens of millions of users, and billions of lines of production code later, it's not worth the disruption. It's not worth "breaking" hundreds of Python books (a few of which I've written). Saving a newline—or even very slightly changing the emphasis of code as read—are not close to worth including the extra way to do the same thing.

Of course the balance might be different for something really cumbersome to do with existing syntax. This isn't that.

On Mon, Mar 7, 2022, 11:34 PM Finn Mason 
PEP 618 (zip(strict=True)) and PEP 616 (str.removeprefix) originated on python-ideas and were accepted.

Even more recently, PEP 680 (tomllib in the standard library). The python-ideas discussion was short and very positive. Then the PEP was written and the "meat" of the discussion was done on