This requires getting all of the framework, gem, and plug-in authors everywhere to agree on standards for everything. If even one goes his own way and writes his own idiosyncratic thing that conflicts with a "standard" thing, there are going to be problems.

I just can't see this scaling, it's a Tragedy of the Commons in the making.

Let me flesh it out a little bit more.

I'm not suggesting there be a canon. I'm thinking of the way github does gems, where the gems are all namespaced with a username. There could be 20 versions of array#sum, but the one that the pioneers/influencers/cool-kids-who-write-frameworks decide to use is the one that gets used. If someone decides to go their own way, someone else will fork and fix.

Maybe conflicts could be detected at the gem level via gems exposing the names of the monkey patched methods they contain.

Honestly I think git/github fundamentally changes some things and that we as a culture haven't yet fully adapted our thinking to the new possibilities.

Of course there will always be problems, and maybe this is utopian crazy talk, but the natural "that can't possibly work" reaction might be worth questioning.

EDIT:

Allow me to go from just crazy to total nutter: a language market where the commodity is semantics and the currency is popularity. If it were given influence over language design would it be an improvement over the benevolent dictators (Larry/Matz/Guido) or an epic fail?

Once pasta chef Katz is done turning the rails spaghetti into merb-style ravioli and all the rails monkey patching is self contained in an extlib style gem, how many projects will begin including that monkey patching as a dependency?

If someone wants an array#sum there's a good chance they'll just depend on rails' array#sum. With its massive influence the rails project has the, perhaps small, potential of becoming an autocratic second-level Matz with a default set of widely used ruby extensions. What Facets wants to be but isn't.

Given that scenario, is it better to let rails be the guardians of a defacto "standard" extlib or to have a more fine-grained system that allows the marketplace of popularity to decide what gets to be considered standard?

With rails recipes the division of labor between programmers and "editors" has already begun. The granularity of the web framework has changed from the single monolithic option handed down by the programmers to the gem level. Now we get a default framework from the programmers and dozens or hundreds of remixed frameworks provided by people with specific configuration needs.

These people are doing the same job that the creators of linux distributions are doing. It's up to them to resolve compatibility issues and create any patches needed to make their distribution work. You find the custom framework that does exactly what you need or if it doesn't exist you create it and become an editor yourself.

Now take the component granularity down to the level of a single language extension or monkey patch. Gems might have gem recipes. The authors of the classifier gem would require array#sum and identify a default version, but an editor could change that.

Right now you can create a recipe that replaces prototype with jquery. Maybe someone thinks that rails' #try sucks so they create a recipe that replaces it with raganwald's #try. It's then the job of the editor to make sure all the components of their recipe play nice with each other.

Just like there are more mutual funds than there are stocks you get an explosion of recipes, but that's exactly what you want. Mass customization. You look through the directory and find the package/distribution that does exactly what you need. The software that gets used gets used.

The key here is that no one needs to agree on anything. Coders code and editors edit. The producer->editor->consumer relationship is natural. The producer->consumer relationship is artificial. It's a bug in the system.