Double down on actors and async I/O, make scheduling preemptive like the Erlang's VM does, and make message passing the preferred way to do multicore-CPU-enabled work.
Nobody is requesting new language features for ages now. They are very rarely needed. The runtime is what needs a lot of work.
Yes they do but that won't help you if one bad actor (literally and figuratively) takes a long time to execute a single function call. Erlang's VM has machinery to multiplex actors on separate CPU cores and keeps around several different kinds of thread pools -- native (as in Erlang bytecode) actors, dirty I/O threads (where potentially long-lived I/O will live) and dirty CPU threads (where CPU intensive tasks go) -- and can move actors between them (although let's be honest, nobody can make that work reliably and Erlang makes mistakes there as well).
Basically, as they call it, several different schedulers, each with its own pre-warmed thread pool.
An event loop is a step in the right direction. I am just worried that Ruby 3.0 might turn out how OCaml Multicore is turning out -- an endless saga.
Nobody is requesting new language features for ages now. They are very rarely needed. The runtime is what needs a lot of work.