brief summary of that issue:

Recall that for a syntactic generator, a return statement provides the value to be used alongside the first { done: true }, as in let g = (function* (){ yield 0; return 1; })(); console.log(g.next(), g.next(), g.next())

this is accomplished by, GeneratorStart evaluates the function body to completion, after which it checks whether it ends up with a return completion (in which case its value is used to give the value of the final iterator result) or a normal completion (in which case there was no explicit return statement, and it ignores the value of the normal completion and uses undefined)

built-in generators use the GeneratorStart machinery with an abstract closure instead of a function body, but I don't think it makes sense for them to use the "check for return vs normal completion" logic. there's a few ways to accomplish this.

one way is to have GeneratorStart assert that the AC produces either a throw completion or a normal completion containing unused, which would mean that GeneratorStart would go down the path for implicit returns from syntactic generators. then built-in generators could never have { done: true, value: "something other than undefined" }, which seems fine though it's kind of an odd restriction to build in.

another would be to assert that the AC produces either a throw completion or a return completion, and require the AC to explicitly return ReturnCompletion(*undefined*) instead of NormalCompletion(~unused~). Then GeneratorStart would go down the path for explicit returns from syntactic generators, and use the value of the return completion to provide the value slot.

I'd mildly prefer the second but am fine either way. Currently we have no asserts in either direction, such that the AC used to define a built-in generator can return both normal and return completions and go down either path, which seems unnecessarily complicated.