Jonah, that's a pretty compelling use-case. You've convinced me that it's a place where auto-closing editors will produce a bad user experience.
However, clearly we can't retain full editor states for an unlimited number of editors. At a certain point, performance degrades intolerably... and at a certain point beyond that, Eclipse crashes due to running out of SWT handles or heap space. If you reach that point you'd also lose your undo stack.
Why don't we do some performance measurements, and pick the largest number of editors we possibly can before the performance becomes unbearably slow or anything crashes on a 32-bit VM -- and only close editors at that point.
So we could turn on auto-close editors but make the number of editors as big at we can before performance degrades too much, and we can collectively decide what we feel to be "too much". That way you'd normally be able to keep your undo stack, but Eclipse could still resort to discarding an undo stack if it has no other alternatives but to freeze up or crash.
- Stefan