Cooperation is dandy if n = 2, but for n > 2, this can get cumbersome. Unfortunately method names like 'sum' are very attractive.
A language/library designer shouldn't have to think of "all of the short or otherwise possibly overloaded nouns and verbs people might like to use, ever." Being able to say you are going to do a 'sum' which means X in this particular context is very powerful.
This notion should also be unified with version control. (As in OS X, where a process only sees the versions of libraries that it is supposed to run against.)
A language/library designer shouldn't have to think of "all of the short or otherwise possibly overloaded nouns and verbs people might like to use, ever." Being able to say you are going to do a 'sum' which means X in this particular context is very powerful.
In this specific case, what's needed is more abstraction. Consider the approach Haskell takes:
It seems to me that worlds permit sharing immutable data structures, and that Warth & Kay's operations on worlds do not permit sharing mutations done in parallel worlds.
The Worlds paper you cited [http://www.vpri.org/pdf/rn2008001_worlds.pdf] cites the COP overview paper [http://p-cos.net/documents/contextl-overview.pdf] mentioned near the top of the link jrockway gave. Warth & Kay say "Similarly, in order to support context-oriented programming (COP) [8], we may want to add a third key to our lookup table that identifies a context." So that gives me some confidence in my interpretation.
FWIW, ContextL is closer to the solution:
http://common-lisp.net/project/closer/contextl.html
But it's still better to just add a standard "array that does 'sum'" to the language, or for Rails and Classifier to cooperate.