I don't see a pressing need to use RVM in production; when I deploy, I pick a Ruby version and stick with it unless there's a security issue, at which point I pull the updated REE package from Phusion/let Heroku figure it out.
Considering the many times I've seen RVM installs fail due to checked-in broken code, I'd hardly call it "production ready" either.
The complete lack of a changelog doesn't help either. I never know whether something's going to break in a new release and almost every new release has some little semantic change that borks my system.
I have to use rvm in production because debian/ubuntu install ruby 1.8 and I need 1.9.2 for rails 3. Ruby isn't in the alternatives system (yet - coming soon) so I don't see a better way.
1.9.1 is there, 1.9.2 is not. But I still the the better solution is to build from source on each machine, or create a custom 1.9.2 package for the machines you will be using. As other comments have pointed out, RVM is held together with string and duct tape and breaks frequently. I haven't dug into the code from this project, but being more testable and maintainable would be one of the biggest wins they could achieve from my point of view.
I have to contradict you (unless I'm misunderstanding you): the debian package named ruby1.9.1 is actually 1.9.2. The 1.9.1 refers to the ruby ABI. Blame the ruby devs for breaking the ABI in a minor version update (1.9.0 -> 1.9.[12]).
That's the goal, and that's why rbenv does not perform compilation/installation at all (there's a separate ruby-build project for that: https://github.com/sstephenson/ruby-build).
Considering the many times I've seen RVM installs fail due to checked-in broken code, I'd hardly call it "production ready" either.