> I hear what you are saying, but the "generalization" does not mean
> that they work exactly the same way.

Correct.  But it does mean that the functionality of one (generator expressions) is a superset of the functionality of the other (list comprehensions).  That is currently not the case.

> The whole point of generators is that execution is lazy, which is
> what leads to the difference in behavior.

No.  That the innermost generator isn't closed over its free variables is what leads to the difference in behavior.

> The generator function *is* closed over the free variables.  That's
> what leads to the difference in behavior: the generator uses the
> value the free variable has when the generator executes.

We're using the term "closure" in two different ways.  Coming from a FP background (where comprehensions first found their way into programming languages), I mean it to close over the value of the variable.  I understand that in Python it closes over the variable itself.  In the context of a comprehension, I claim that the latter is useless and surprising behavior.

> I don't believe there is any practical way to implement what you are
> suggesting

Again, please see the example in my original post.  The generic algorithm is simple: for every generator expression syntactically nested inside another, walk the AST of the inner generator expression's output expression.  Do not enter lambdas.  Recursively apply this algorithm for any generator expressions syntactically nested in the inner generator expression.  For every variable referenced which is not bound by the inner generator expression, add it as a parameter to the generated inner generator function, and add it as an argument when calling the inner generator function from the outer generator function.

> even if we wanted to...which we would not be, since it would
> constitute a backward incompatible change in behavior.

You can't honestly tell me anyone relies on the current behavior of nested generators.

Furthermore, my assertion is that the current behavior is in violation of the language specification.  If "backward-incompatible changes in behavior" was a legitimate excuse for refusing to remedy implementation/specification disparities, then it would apply to every Python bug ever.