... and that won't be updated when Apple issues their updates

Basically, you'll be maintaining and distributing your very own fork of MacRuby.

The flipside of that is actually pretty important too: Apple can rely on their "private" version of Ruby not being randomly updated underneath them because the user wanted to install cool-rails-app-de-jour.

This is pretty important if Apple are planning on using Ruby for important OS tasks.

(and now I'm officially feeling old - who else remembers this exact same argument from over a decade ago? Did the "private" Sun perl binaries catch anyone else out? How many times did I cause myself trouble forgetting to type #!/usr/local/bin/perl instead of #!/usr/bin/perl ?)

The FreeBSD ports install perl under /usr/local anyway, just like almost every other piece of software in the tree. After a while you get used to it, and like the separation of base system from installed software.

You shouldn't be able to update the system's MacRuby (or anything else, for that matter). Doing this is pretty suicidal.

And your old Perl problem is a Python problem for me. Too many Red Hat servers have 2.4 installed where Python is supposed to be. I have to build my own and call it from the /usr/local tree

This doesn't sound like a bad thing, as an app will likely need to be updated when the framework changes.

Why? My Python code usually works with anything 2.4+ (some of it prefers 2.5+). Why would MacRuby code be any different?

Linking to a shared library should be painless unless the public interface changes in a way your app breaks.