@ljharb here's what i think RegExp.prototype[@@matchAll] would look like. Obviously though we can't do this now because RegExpStringIteratorPrototype is observable.

<p>RegExp.prototype[@@matchAll] is a built-in generator function which, when called, performs the following prelude steps:</p>
<emu-alg>
  1. Let _R_ be the *this* value.
  1. If Type(_R_) is not Object, throw a *TypeError* exception.
  1. Let _S_ be ? ToString(_string_).
  1. Let _C_ be ? SpeciesConstructor(_R_, %RegExp%).
  1. Let _flags_ be ? ToString(? Get(_R_, `"flags"`)).
  1. Let _matcher_ be ? Construct(_C_, &laquo; _R_, _flags_ &raquo;).
  1. Let _lastIndex_ be ? ToLength(? Get(_R_, `"lastIndex"`)).
  1. Perform ? Set(_matcher_, `"lastIndex"`, _lastIndex_, *true*).
<emu-alg>
<p>The body of RegExp.prototype[@@matchAll] is composed of the following steps:</p>
<emu-alg>
  1. If _flags_ contains `"g"`, let _global_ be *true*.
  1. Else, let _global_ be *false*.
  1. If _flags_ contains `"u"`, let _fullUnicode_ be *true*.
  1. Else, let _fullUnicode_ be *false*.
  1. Repeat,
    1. Let _match_ be ? RegExpExec(_matcher_, _S_).
    1. If _match_ is *null*, return *undefined*.
    1. If _global_ is *true*, then
      1. Let _matchStr_ be ? ToString(? Get(_match_, *"0"*)).
      1. If _matchStr_ is the empty string, then
        1. Let _thisIndex_ be ? ToLength(? Get(_matcher_, *"lastIndex"*)).
        1. Let _nextIndex_ be ! AdvanceStringIndex(_S_, _thisIndex_, _fullUnicode_).
        1. Perform ? Set(_matcher_, *"lastIndex"*, ).
      1. Perform ? Yield(_match_).
    1. Else,
      1. Perform ? Yield(_match_).
      1. Return *undefined*.
</emu-alg>

Actually, we might need to add a GeneratorResume before Return _generator_. to allow the generator to have an initial time to do things like check its argument types. The steps of a builtin function would Yield() once after initialization. Alternatively, we could split the steps into a "prelude" and "body" where the prelude is eagerly evaluated, and the body is evaluated in the generator context.

Why couldn't we do it now? The only observable part is the toString's native code, which wouldn't change.

@ljharb because RegExpStringIteratorPrototype is observable, we can't stop having the function return it.

ahhh right, so to make this PR maximally useful, we'd have to have a way to control the [[Prototype]] of the returned iterator (since we'd want to use this approach on all the iterators in the spec, i'd think)