> I think we would agree that foreach fits the definition, happy path, and whole purpose of a polyfill

I think you got that all wrong and strongly misinterpret "modern functionality" as some generic library here...

Runtimes are developed against a certain spec, in this case ECMAScript, and "modern functionality" is meant as addition to iterations of such a spec. As it happens, iterations of specifications and runtimes are seldomly provided by the same entity, so both are moving forward with newly supported features, or more "modern functionality", individually.

This behavior provokes some difficult challenges for developers. For once, they would like to work against the latest spec with its newest features, but, due to the natural dynamic of various entities doing things in different ways, these developers would also need to support older/other runtimes where such a feature is not (yet) implemented natively. Now, to bridge these supported-feature-gaps developers came up with an interesting concept: Instead of waiting and relying on the runtime to support such a new feature, it might be possible to provide an implementation as workaround, hence the "polyfill".

So, if something A isn't currently in the spec, nor B even proposed or in discussion to be in the spec, nor C provided by any current runtime (and relied upon by developers), then I'd conclude that such a functionality is not considered to be a polyfill, as it isn't to be seen as workaround for the supported-feature-gaps due to the difference in runtimes.

> I think you got that all wrong and strongly misinterpret "modern functionality" as some generic library here...

I didn't. I am telling you exactly why polyfills exist, and why people use them.

More importantly, I am explaining to you why this scheme is successful.

You don't need to write any wall of text that adds nothing. Read the facts I laid out, and use that to either understand how things work, or don't. It's your choice.