Due to how Iterable is specified now it does not promise multiple iterations, but due to how most (all that I know of except DirectoryStream or some 3rd party) Iterables are implemented now, the common expectation is that it does. By implementing more Iterable(s) that don't support multiple iteration (regardless of whether they implement this new sub-type or not), this expectation will be less and less honored. Perhaps this is not so bad. At various occasions the specification has been changed to accommodate the long-standing behavior or expectation of behavior, but this seems not to be one of them.
Correct. But, with separate Iterable and IterableOnce, the spec for Iterable can say "If you don't support multiple iteration, you should implement IO." Which is OK, because at least those classes are being explicit.
Let's pretend for a moment that Iterable specification was changed to guarantee multi-pass iteration. In that case the IterableAtLeastOnce as a supertype of multi-pass Iterable would make much more sense, wouldn't it?
Then we couldn't use Stream in foreach without a language change, which is the whole point of this exercise.
