Postmodern

I finally got around to this in ccae75a26017bfdb2e4ef499c8a6ed5aea00db38.

There could be problems with gems that used internal C functions that were added in specific 1.9.x versions.

However, RubyGems 2.2.0 how keeps built C extensions in a separate `extensions/` directory: ``` extensions/ `-- x86_64-linux `-- 2.1.0-static `-- bond-0.4.3 |-- gem.build_complete `-- gem_make.out ```

The change might be as simple as `export GEM_HOME="$HOME/.gem/$RUBY_ENGINE/${RUBY_VERSION%.*}"`.

Another blocker is that rubygems has generated fully qualified `#!` for it's binstubs, instead of the usual `#!/usr/bin/env ruby`. This makes it difficult to share rubygems between multiple Rubies.

Unfortunately there is no `GEMOPT` env variable we could set to enable the `--env-shebang` option by default.

Probably a good idea to document `--env-shebang` and `gem pristin`. Long-term, I wish `#!/usr/bin/env ruby` would be the default, and `#!/path/to/ruby` would only be used when `ruby` has a custom...

Unfortunately using the API version would mean no gem separation between different versions. Also keep in mind that rubygems now generates an absolute `#!/path/to/ruby` for gem executables.

Ah it appears ruby-core is bumping the API version on each minor release, instead of having one API version for all 2.x.y releases. This might work after all. I still...

Actually you could use `Gem.ruby_api_version`.