[Nick Coghlan <ncoghlan@gmail.com>]
> ...
> Using a new keyword (rather than a symbol) would make the new construct
> easier to identify and search for, but also comes with all the downsides of
> introducing a new keyword.

That deserves more thought.  I started my paying career working on a
Fortran compiler, a language which, by design, had no reserved words
(although plenty of keywords).  The language itself (and
vendor-specific extensions) never had to suffer "but adding a new
keyword could break old code!" consequences.

In practice that worked out very well,  Yes, you _could_ write
hard-to-read code using language keywords as, e.g., identifier names
too, but, no, absolutely nobody did that outside of "stupid Fortran
tricks" posts on Usenet ;-)  It had the _intended_ effect in practice:
 no breakage of old code just because the language grew new
constructs.

It's no longer the case that Python avoided that entirely, since
"async def", "async for", and "async with" statements were added
_without_ making "async" a new reserved word.  It may require pain in
the parser, but it's often doable anyway.  At this stage in Python's
life, adding new _reserved_ words "should be" an extremely high bar -
but adding new non-reserved keywords (like "async") should be a much
lower bar.

That said, I expect it's easier in general to add a non-reserved
keyword introducing a statement (like "async") than one buried inside
expressions ("given").