I think that's more of an implementation issue, rather than a problem with the idea of comprehensions. In set builder notation you can order elements as you like without changing the semantics. So you can denote the following "nested membership" statement in either order:

  X = {a | A ∈ Y, a ∈ A }
  X = {a | a ∈ A, A ∈ Y}

But in Python, changing the order changes the meaning:

  >>> Y = (('a','b','c'), ('d','e','f'))

  >>> X = [a for A in Y for a in A]
  >>> X
  ['a', 'b', 'c', 'd', 'e', 'f']

  >>> X = [a for a in A for A in Y]
  >>> X
  [('a', 'b', 'c'), ('a', 'b', 'c'), ('d', 'e', 'f'), ('d', 'e', 'f')]

It's the difference between declarative and imperative semantics- a kind of declarative-imperative impedance mismatch, if you like. The set-builder notation tells you how things are, timeless and unchanging. The imperative notation tells you how to get there.

Consequently, you can't just throw any set of comprehension elements together and hope that you'll get something that makes sense. This messes up the elegance of the notation considerably, and it also makes it very, very fiddly to write some things that you might conceivably want to write, so much so that it ends up being much more readable to write a traditional for-loop, than use a comprehension.

There might even be orderings that are not allowed by the Python compiler, even though they might make sense in a declarative formalism. I can't think of any right now, but I'm pretty sure there are plenty- and lambdas are not going to be a get-out-of-jail-free card either.