I do think there is some potential for errors caused by misunderstandings about whether or not "for x in y" is destructive. That's the thing that worries me the most. I think this is the main reason why the old practice of abusing __getitem__ was bad, and thus helped to motivate iterators in the first place. It seems serious enough that migrating to something that distinguishes destructive-for from non-destructive-for could indeed be worth the cost.
I'm not sure I understand this (this seems to be my week for not understanding what people write :-( ).
First of all, I'm not sure what exactly the issue is with destructive for-loops. If I have a function that contains a for-loop over its argument, and I pass iter(x) as the argument, then the iterator is destroyed in the process, but x may or may not be, depending on what it is. Maybe the for-loop is a red herring? Calling next() on an iterator may or may not be destructive on the underlying "sequence" -- if it is a generator, for example, I would call it destructive.
Perhaps you're trying to assign properties to the iterator abstraction that aren't really there?
Next, I'm not sure how renaming next() to __next__() would affect the situation w.r.t. the destructivity of for-loops. Or were you talking about some other migration?
--Guido van Rossum (home page: http://www.python.org/~guido/)