Kevin Gibbons

> it seems like the correct test would be that name appears _right after_ length, right? Right. > I think Web IDL, being more imperative than the ES spec, actually...

If it's intended, that's fine with me. (The behavior in #1138 does work with the ES spec as currently written, though we didn't really intend for it to when we...

> reusing %MapIteratorPrototype% and %SetIteratorPrototype% is something all engines do I couldn't find any examples of this right now, poking around a little, though it's entirely possible I've just missed...

I don't think any option here is likely to actually affect users in any noticeable way, so I am personally fine with any outcome here. I _do_ think some choices...

> To the best of my knowledge, I have maintained consistency with real Map iterators Yeah I think you're fine currently. The main details to worry about are iteration order...

> So afaict this shouldn't be a big issue for Chrome, at least; we'll just continue using distinct code that's written to intentionally match Maps/Sets in behavior but without expectation...

It's probably worth noting that all major engines also reject such programs, contra spec.

Oh, and see [old spec bug](https://bugs.ecmascript.org/show_bug.cgi?id=4243) relating to this, which never got resolved.

The spec question has finally been resolved in favor of making a normative change to match the behavior in most implementations, including esprima. See https://github.com/tc39/ecma262/pull/1158. I think this can be...

It (and basically everyone save Firefox) similarly incorrectly accepts `({ g\u{65}t x(){} })`, and probably escape sequences in other contextual keywords too. Edit: a slightly expanded list of invalid programs...