I love Ruby, use it for most of my projects that don't require performance.
Nothing I would love more than a Ruby with a Common-Lisp like compiler and runtime. Unboxed types, native compilation, partial compilation, live image (Ruby has this but "faster Rubies" like Crystal don't), etc...
I have a (self-hosted, but buggy and wildly incomplete; don't try to use - jRuby or TruffleRuby are better - and far faster - options) Ruby compiler that was partly born out of wanting to figure out what this would take, and the answer is it is massively painful because Ruby has failed to take some basic steps that makes delineating read-time and run-time very hard (e.g. you have fun patterns like overriding "require", and iterating over directories to decide what to require) even though most Ruby programs do have clearly separate load and run phases. It's just hard to programmatically separate it.
I still believe you could do pretty well there with a few basic "tricks" that could still also remain real/valid Ruby, by recognising the most common patterns, documenting them, and providing a way of marking exceptions. Combine that with freezing system classes after startup as an enabler for various optimization, and a compiler could do a pretty good job. But it's a massive piece of work to get it right for Ruby.
Common Lisp, and even more so Racket, has reader macros. With a little help from LLMs you might be able to get a Ruby-like language that translates into Lisp.
As a last resort look at Racket's "Rhombus" language, it's basically an infix, Python-like syntax on top of Racket. You can use that or see how they pull it off and add Ruby constructs to it.
Nothing I would love more than a Ruby with a Common-Lisp like compiler and runtime. Unboxed types, native compilation, partial compilation, live image (Ruby has this but "faster Rubies" like Crystal don't), etc...