Philip Chimento

Following up from #4038, I think it might help to have additional coverage for ASCII strings (to help debuggability in case an implementation gets single characters right but surrogate pairs...

I looked through the tests at a high level and they seem correct. I'm working on documentation for how to write a testing plan and this proposal seemed the right...

Landing this is fine with me. NB, I did not confirm each numerical result in the numerical tests, I'm prepared to trust @bakkot on that. I haven't looked at whether...

I think that might indeed be a misinterpretation of that step. That January spans two era/eraYear pairs, Showa 64 and Heisei 1. It's not two separate Januaries, so the PlainYearMonth...

I'm trying to put together guidance on writing a testing plan, so I thought I'd use this proposal as a sample. There may be some things in this list that...

- is extensible / Function.prototype: I've found that many existing functions do actually test these! That's how they found their way onto my "boilerplate" list :smile: I've been toying with...

> However, how should we handle the result of `Function.prototype.toString` for built-in functions with invalid names as identifiers (e.g., `RegExp["$+"]` that is not standardized yet)? It is not standardized yet,...

Actually, I see there already is such an issue: https://github.com/tc39/proposal-regexp-legacy-features/issues/19

Just to be clear, this is separate from the special treatment of `Etc/UTC`, `Etc/GMT`, and `GMT` which would need to remain for backwards compatibility? (https://tc39.es/ecma402/#sec-canonicalizetimezonename)

Justin already covered most of the feedback I'd have given. I have only a minor thing to add. I'd recommend avoiding the name `name` because I always find it ambiguous...