It's kind of weird to do this given that we don't do it for yield*, which is explicitly the "forward the result" operator.

I'm not totally opposed but it isn't obvious that this would be a perf improvement anyway, because now engines can't assume that the result of Iterator.concat is itself a well-behaved iterator result object. I have a doc about how engines could skip the allocation of these objects for built-in iterators in the common case of consuming the result as an iterable, but you wouldn't be able to do that optimization for Iterator.concat if we made this change.

Iterator.prototype.{ take, drop, filter }

Assuming we do this, we should also do this (as a follow-up) for yield* and Iterator.prototype.{take,drop,filter}. We shouldn't blindly follow their precedent here.

It's kind of weird to do this given that we don't do it for yield*, which is explicitly the "forward the result" operator.

yield* forwards the iterator result object. https://tc39.es/ecma262/#sec-generator-function-definitions-runtime-semantics-evaluation:

i. Let innerResult be ? Call(iteratorRecord.[[NextMethod]], iteratorRecord.[[Iterator]], « received.[[Value]] »).
...
v. If done is true, then
...
vi. If generatorKind is async, set received to Completion(AsyncGeneratorYield(? IteratorValue(innerResult))).
vii. Else, set received to Completion(GeneratorYield(innerResult)).

It's maybe possible to change yield* to not forward the iterator result object, because JSC already has this behaviour: https://bugs.webkit.org/show_bug.cgi?id=174756.

Ah jeeze, that's what I get for testing in a browser instead of actually reading the spec.

I opened a needs-consensus PR for 262: tc39/ecma262#3489