If you had bothered to check his profile, you’d see he joined here only 13 days ago.
If you’d checked his activity and read this user’s threads and questions that were asking (about overriding native tools, etc.,) the “newbness” is evident.
It was never seriously implemented in SketchUp. SketchUp does not correctly supply a "config.rb" that actually reflects the SketchUp install. (The path returned by several Gem methods are just “out of the box” paths from the incorrect "config.rb".)
EDIT: Yes I mean "rbconfig.rb" (… was in a hurry, mind on other things.)
I’ve discussed this at length with Thomas and it is clear that SketchUp never did what is explained should have been done in the "rubygem.rb" lib (loader) file, … in comment section:
# == RubyGems Defaults, Packaging
In your other thread …
We talked about it, and it was rejected. Commercial extension developers rely upon SketchUp’s environment to be “clean” and controllable. Many of us did then and still do not want SketchUp placing requirements upon our “system” Ruby installs. So it only made good sense for SketchUp to distribute it’s “own” Ruby implementation.
But it’s rubygems configuration was “quick and dirty” and is still (since SU2014) not reliable.
Adding a multitude of gem possibilities outside of SketchUp’s influence creates problem scenarios and adds to Trimble’s support overhead. It would be a support nightmare for them. They just will not do it. (It’s “beating a dead horse”.)