@jeremyevans0 (Jeremy Evans) The specs were added in https://github.com/ruby/spec/pull/1127 (so not written by Andrii, but reviewed by him).
Adding specs is how we discover this kind of strange behavior.
But it's not always clear if intentional or not, and unfortunately for compatibility other Ruby implementations might even need to be bug-compatible with CRuby in some cases (because some gems might rely on the weird/buggy behavior, or CRuby considers it too incompatible to fix some weird behavior).
In general it's encouraged to file an issue here if the behavior looks weird and use ruby_bug
with the expected behavior, if it's clear what that is, and there is a good chance CRuby will fix it.
This was done later in this case, while improving the specs in a truffleruby PR and discovering the unexpected behavior.
BTW I don't even see in the original PR a spec covering the behavior of this issue (only #20607).
IOW please do not be annoyed by this, ruby/spec is trying to test Ruby better and sometimes the behavior is weird so it's spec'd as current behavior in CRuby, and discussed here, and maybe it's fixed in CRuby, and of course tests/specs should be updated to avoid any regression and test the fix.
So the tests/specs should be updated anyway.
I think this situation is unavoidable to some extent, since CRuby is the reference implementation and its behavior very much dictates the specs, and we need to spec as much as possible to ensure compatibility between Ruby implementations.
There are so many edge cases in CRuby, it is often hard to judge if intentional or not, and whether third-party code might rely on the current behavior.
I also understand why you might be annoyed by this, ruby/spec reviewers try to catch such cases early but nobody is perfect, and I think we should be thankful for more tests/specs, even if that means a bit more effort updating them when fixing a bug/strange behavior.