The more the merrier. MS supports research into compiling many
(dyn)langs into DotNet/CIL. Python seems to be their main dynlang
target with IronPython. They want broad support for their DotNet/CLR
env and dynlangs is an interesting "niche" for the future. Why worry;
we need more compilation alternatives for Ruby. The rumour has it that
the next version of DotNet/CLR will have much improved support for
dynlangs.

We (a student of mine, myself and Hal Fulton) worked on a Ruby to CIL
compiler some time back but didn't get that far because of limited
time and resources available. I still have hopes to take this up in
the future.

DotNet/CIL is interesting mainly from a commercial viewpoint IMHO;
there are many high-quality libraries available for it which can be
used either with a CLR bridge like RubyCLR etc or, more directly, from
a Ruby2CIL compiler. This should be a good thing since it expands on
the possible scenarios in which you can use your Ruby skills and do
useful stuff (by gluing good libs together for example).

However, there are also other potentially good sides with a Ruby2Cil
compiler. IronPython also shows that good performance can be achieved;
on some benchmarks it even beats the C-implemented and over-many-years
highly tuned standard Python implementation. The potential for a
Ruby2CIL compiler might be even larger when it comes to performance
since the current Ruby compiler is AST-eval based and (I think -
without having any real, hard devidence -) have, on average, somewhat
lower performance than the Python one.

My 2 cents,

Robert Feldt