[...] The correct choice depends on the reader context.
I don't think so: The choice mainly depends on the size of the scope where a name is valid. If you have e.g. a one-line comprehension, I don't see any point in having a long descriptive name for a name only bound within this comprehension, it just makes reading harder and more tedious. OTOH, if you have an API entry point (i.e. a huge/global scope), a longer descriptive name is far better. And even then: The initial assumption seems to be that people will pick good long names, but this doesn't match with my experience: People who write incomprehensible code usually pick incomprehensible/silly/misleading names, too. OTOH, clear, well-structured code is very readable even with f, g, x, y, ...
[...] The todays text-as-the-primary-representation approach however forces
the author to make a pick already when writing the code.
The fictitious example forces the author to come up with a good long name (which I guess won't work most of the time). How could the IDE come up with a long name otherwise? I would simply refuse to give a name in a one-liner comprehension a long name, what for? And shortening long names in a sensible way doesn't look easy either.
As others have already mentioned before: The idea of having AST editors instead of text editors comes up again and again for several decades, and no one has come up with a nice working IDE yet which people actually want to use in day-to-day work. It's simply hard to beat the efficiency of people trained in typing text for decades in a text-based editor. The idea seems to be good enough to produce some research work and/or conference papers, but not really much more...