The recipe has been in the docs for a good while and as far as I can tell, no one ever uses this in real-code.  That suggests that it should remain as a recipe and not become part of the core language (feature creep is not good for learnability or maintainability).

I also don't see people writing simple generators that exhibit this functionality.  It just doesn't seem to come-up in real code.

[Josh]
> I've had several cases where I'd have used something like this 

Please post concrete examples so we can actually assess whether code is better-off with or without the feature.  

FWIW, the standard for expanding the API complexity of built-in functions is very high.  It is not enough to say, "I might have used this a couple of times".  

Unnecessary API expansion is not cost free and can make the language worse off on the balance (does the time spent learning, remembering, and teaching the function payoff warrant the rare occasion where it will save a couple of lines of code?  is code harder to customize or debug with hard-wired functionality rather than general purpose try-excepts?  Do we even want people to write code like this?  If heaps, deques, dicts and queues really needed to be destructively iterated, we would have long since had a feature request for them.  But we haven't and destructive for-loops would be unusual and unexpected for Python.