Collecting some of my comments on this here from the original thread, so that it may be closed:

Would that make the error handling potentially weird, though? Let"s say that a user does this:

const src = "{n is {$n :number minimumFractionDigits=999}}";
const mf = new Intl.MessageFormat(src, "en");
const parts = mf.formatToParts({ n: 42 }, console.warn);
for (let part of parts) console.log(part);

With array output, it"s pretty clear that the console.warn call will happen before the console.log calls. But with an iterable that"s formatting parts lazily, that might log:

{ type: "literal", value: "n is " }
RangeError: invalid digits value: 999
{ type: "fallback", source: "$n" }

whereas a more eager implementation would report the error earlier.

I think we do want an array. Not because we may want to read its length or access parts by index, but because:

1. It"s clearer to the caller that onError will never be called after the function has returned a value.
2. It"s much more user-friendly to allow resetting the position within the parts.

@stasm It would be helpful to have an example or two of use cases which "may benefit from a more lazy approach made possible by the use of generators".