I have to say that I'm really surprised that this idea is gaining this much traction. And this is why:
Shorthand for a list of stings, whether this proposal, or the "list of strings".split() "hack" -- is useful primarily for what I"d call "scripting",rather than "software development".
There is not clear distinction, of course, but in (my definition of) scripting, the write:read ratio (and the write:everything-else ratio: e.g. runinng, testing, debugging, reviewing) is much higher, and it is a lot more common to have a bunch of literals. I know I often put a pile of literals a the top of a script, whereas a program would use a config file, or command line arguments, or pull data from a database or web service, or .....
So why am I surprised? Because Python, over the years, has become more of a "programming language", and a bit less of a scripting language.
print x => print(x) is a prime example -- but there are many others.
I'd say f-strings are the only exception I can think of of a feature that is probably more useful to "scripting" than "programming". But less so than this proposal.
On to this one -- despite the fact that I do a fair bit of quicky scripting, I don't think this is worth it -- it's really only useful for a particular subset of lists of strings -- once you add escapoing whitepace and all that (and what do you do with quotes?, it isn't a good general solution. Sure it's a common use case, but then, the "a bunch of words".split() solution is fine in that case.
As for "one obvious way to do it" -- that is aspirational -- there simply can't be one obvious way to do everything. And sometimes "it" is not one thing. I'd say:
if you need to build a quick list of simple single words that isn't likely to get more complex, then use .split(), if you need to build a list of strings that are not simple words, and/or may get more complex, then use the full set of quotation marks.
Final point: ideally, we all have editors that help with the quotes, so it's not *quite* as much extra typing.
TL;DR -- not a really wide use case, and makes the language that much more "PERL-like".
-CHB