In the forEach section [1], Step 9.3 of the “If the interface has a maplike declaration or setlike declaration...” algorithm says “Call the [[Call]] internal method of callbackFn with thisArg as thisArgument and v, k and object as argumentsList.” This value followed by key ordering is consistent with ES6 Map [2] and Array [3].

However, step 4.2 of the “If the interface has an iterable declaration...” algorithm says to “Invoke callback with thisArg as the callback this value and k and value as its arguments.” This would appear to cause the opposite order of parameters being passed to the callback. Is this intentional?

Also, [4] says “If two type parameters are given, then the interface has a pair iterator and provides value pairs, where the first value is a key and the second is the value associated with the key.” Thus, the “value” passed to the interface is [key, value], which is similarly inconsistent.

My interpretation of the current text is that forEach() callbacks would receive the following parameters based on the declaration type:
* For maplike declarations: (somevalue, somekey)
* For iterable declarations with a single type parameter: (index_k, somevalue)
* For iterable declarations with two type parameters: (index_k, [somekey, somevalue])

It would seem more consistent (and correct for ECMAScript language binding?) for the callback for iterable’s forEach() to receive the following instead:
* For iterable declarations with a single type parameter: (somevalue, index_k)
* For iterable declarations with two type parameters: ([somevalue, somekey], index_k).

[1] http://heycam.github.io/webidl/#es-forEach
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map/forEach#Description
[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach
[4] https://heycam.github.io/webidl/#dfn-pair-iterator