Again: you are using two libraries (Rails and plugin X) that depend on their own versions of try, which they include.

One of the libraries is going to break.

Indeed. It's probably wise to use namespaced internal methods inside of libraries or frameworks. However, Rails has historically pioneered new language features that eventually make their way into the language itself (Object#tap, Enumerable#group_by, etc. etc.).

In Rails 3, we've made it reasonable to pull in just small pieces of the ActiveSupport library, making it more likely that users will reuse functionality from there rather than reinvent the wheel.

Of course, it's not perfect.

Am I right in thinking that once a piece of ActiveSupport is pulled in anywhere in the codebase it will affect ALL Ruby objects, rather than having its effect scoped to just the module that included it?

Yep. You'd be modifying the String class itself, not just Strings that find their way into some file.

Well... yes. You're right. If you're depending on one behavior rather than the other, then totally. I guess I was thinking about it more in terms of two different implementations of the same thing. "If we don't have a quicksort defined yet, make one."

This is basically how ActiveSupport's "activesupport/ruby/shim" functionality works. It adds pure-ruby versions of features added in Ruby 1.9 only if they aren't already defined.