"The way I see it, for any new Ruby project, you should start be using with Ruby1.9. If it doesn’t fit your needs, then, consider an alternative."

But first, make sure the alternative implements all of the Ruby you are going to need.

Is there a problem here?

Yes, there is a problem. The problem may not be the many implementations of Ruby but there is certainly a problem.

There should be one Ruby just works or, at the least, different Rubies that can be added and removed only for performance reasons. We aren't there yet and we should be. Multiple Rubies might be a step there. Let's hope.

-- Good choice is when you get lots of choice about what tell your system to do. Bad choice is when you have to make lots of choice about you want the system to do what you tell it. The Ruby language itself has lots of good choice in it. But the "now you can choose lots of Rubies" situation is a bad-choice situation.

For one Ruby that just works, use 1.8 for legacy apps and 1.9 for recent or new apps. Consider the alternatives only to augment or if they are needed for a particular requirement (e.g. JRuby for Java libs, MacRuby for Cocoa, etc.)

If Rubinius doesn't blow all the others out of the water I'll be surprised. Ruby in Ruby feels right.

This is what the RubySpec project is trying to address.