To fix this, should we choose to do so, we have a couple options:

(Regardless of the approach, we would have to put them back on the scope)

• Disable scopeless optimization across the board. This would work, but would also slow down execution substantially for many methods (most of which don't need $_ and $~)
• Disable scopeless optimization only when $_ or $~ are present. This would require that methods which set $~ or $_ gain added smarts to know when they "cant". It's also not foolproof, since you can eval "$~" and get a result, but eval has to turn off scopeless anyway.
• Disable scopeless optimization when $~ or $_ are present or any of the methods that set them are likely to be called. This adds more keyword-like behavior to some methods, and would require we tag such methods as requiring a caller scope, but it would generally be reliable. The same exceptions as for eval deoptimization would apply: if e.g. gets were aliased, we would fail to notice it, and the aliasing could happen "too late" for us to deoptimize some methods that may have been AOT compiled. But we could disable aliasing those methods or something. We could also in JIT mode track at runtimewhether the actual methods being invoked are the ones we expect, which would catch aliased methods (but also require another check for future changes to deoptimize and start over).

The frustrating detail here is that Ruby isn't consistently handling $~ and $_ as though they're local variables, since if the variable has not been assigned in a given child scope, Ruby checks the parent scope. Once set in the child scope, the parent scope is never used again. We've never had that behavior as far as I remember, and it's in my opinion a rather ugly wart.

The move of $~ and $_ to Frame isn't entirely wrong. What Ruby does is store it on the scope, but only on a "topmost" scope in a given scope's parent hierarchy. So a normal block will still share $~ slots with its containing method.

I think the effect we're seeing here is that lambda is not reaching the correct frame on which to make these updates, which now produces the output:

nil
"a"
"c"
nil
"a"
"c"

...because the match only gets stored in the lambda's cloned frame, not in the original containing frame. And sub is also not storing the result into the correct frame.