You're glossing over some of the complexities of this rather interesting situation.

In particular, the guy who wanted to be able to make it a compile-time option had a program that would do basically nothing without readline, and you had to enable it for the program to work. A similar issue is with two-part programs; one part non-GPL, one part GPL, which are left up to the user to link himself.

What matters is not what RMS says (nobody cares about RMS), but what the lawyers say. Apparently, the law is extremely harsh on this sort of "hack", which may seem fine to a programmer, but to a judge will be seen as an obvious attempt to work around the terms of the license and will be greatly punished.

That's not true. If you read the story you'll see that the guy had a working program for years before he used readline. The use of readline only improved an already working program. Not to mention, the program in question was a language implementation and readline had nothing to do with it. It was a user interface perk.

At one point he said he'd distribute a working program without readline or readline support even enabled by default and leave it up to the user to configure it. It was only going to have an interface to readline without including any readline code. He was told he couldn't even do that.

In the end he chose to GPL the entire language implementation. To him, it probably didn't make a difference what the license was and it was easier than replacing readline. Personally, I would have replaced it with a BSD-licensed alternative just out of spite given the way the whole thing was approached. The line about how a judge wouldn't be convinced the program didn't violate the GPL read like a thinly veiled threat to me.

Then RMS was wrong. The SFLC says you're quite allowed to do that, a classic example being ffmpeg, which can be LGPL, GPL, or even non-redistributable depending on what external libraries you link it to on compile-time.

People have to learn that RMS is not God and that just because he says something about the GPL doesn't mean that the lawyers agree.

Does the answer change if foo.py does not ship with bar.py, but nonetheless requires foo.py to function? Does the answer change if foo.py does not ship with bar.py and does not require its presence to function?

If GPL foo.py is the only library that can fill that void, then sure, once your app runs a code path that takes it through foo.py, it's a derivative work. But what something else could fill that void?

For instance, what would happen if Editline exposed a Readline compatibility layer?

What follows is all my hazy recollection. If memory serves, the answer was this, although obviously if you ask RMS you get slightly different answers depending: you have to GPL your code (if you distribute it) if you link to GPL code. If you can plausibly link to several different libraries, not all of which are GPL, you don't. So when readline was alone in the world, everything that used it had to be GPL. The BSD folks wrote editline specifically to avoid this--initially, editline was extremely lame compared to readline and I think might still be, but because the API was equivalent they could say "We're BSD licensed through and through; use our code for anything you want" and still have a non-horrible CLI and yet at link time decide to use the good library.

I think the reason this works legally, although I'm not a lawyer, is because yes, when you link your program with readline that executable cannot be distributed except under the terms of the GPL. Because you have multiple potential targets for this sort of thing, nobody can argue that you are trying to technically evade the requirements.

But apparently this is still contentious.

Sometime last year, I saw an article claiming that because of libedit's existence, we could all link against readline from whatever we wanted (or at least that this showed that the dynamic-linking-is-deriving was crap), but I can't find the article now.