The decision was made to consider the methods from io-wait and io-nonblock one by one.
I think wait_readable and wait_writeable should be fairly non-controversial. They're quite essential to use IO#read_nonblock and IO#write_nonblock effectively.
NB: if we only merge some methods, then io/wait must test which methods it needs to define or not. For now I use a if RUBY_VERSION >= "3.2" check in extconf.rb, but there might be a better approach.
I agree with @ioquatix (Samuel Williams) that it doesn't make sense to make IO#wait_readable and IO#wait_writable core, but IO#wait not, because of their close relation. And similarly it makes no sense to me to IO#leave wait_priority in the gem (that was just badly documented and that can be fixed easily).
The 3 IO#wait_* methods should be together and must stay consistent with one another, and also implementation-wise it's super weird if not in the same place. It's a similar argument for IO#wait.
The controversial methods in https://bugs.ruby-lang.org/issues/18566#note-16 seem ready? and nread.
Those seem fine to leave in the gem (very rarely used, and not so directly related to IO#wait*).
@larskanis That's a good point (it seems a bug).
And IO#wait also evolved more than IO#wait_{readable,writable,priority} IIRC.
It doesn't seem a very stable interface yet, and it's hard to use (STDOUT.wait(IO::READABLE | IO::WRITABLE) doesn't work as expected, it hangs)
All of these 4 methods end up in rb_io_wait() I think, but with a fair amount of code to wrap it.
So I think it'd be fair to leave IO#wait out of core for now then based on these reasons.
I think it'd make sense to include wait_priority, so the 3 wait_* with simple semantics are kept together.
Subject changed from Merge `IO#wait_readable` and `IO#wait_writable` into core to Copy `IO#wait_readable`, `IO#wait_writable`, `IO#wait_priority` and `IO#wait` into core.
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by