We'll probably need to allow it, but I don't realistically believe this dual-methods thing will be among the first things we choose to spend time on. It's really a quite rare special case. I think we might classify it as allowed but preferrably avoided practice (cf. adding methods to Object). The "further in" toward the core, the more we'd try to avoid it unless warranted.
Hmmm...I don't think this is a special case at all...you may be right about it not being one of the first things implemented, but adding methods to Object is done quite commonly (and by necessity). Usually, adding a method to Object is cleaner than trying to avoid doing so (see Andreas' argument in favor of #is* methods over using #isKindOf:). The real problem with doing such is the fact that we don't have a solution for method namespaces. Avoiding such method additions leads to code that is convoluted, difficult to maintain, and generally not well written.
Here, the Compiler creates a String. Are present implementations that allow this smart enough to instantiate a String as it is known in the creating namespace, with the right method defined? Because the Compiler's namespace, when the literal-compiling method is defined, would certainly not know of either of the two definitions.
Your concept of method namespaces is a bit off here. The compiler does not instantiate anything...it only resolves names. When a String is instantiated (in the case where there are two different implementations of #selectorDefinedTwice), the same String class is used (unless you've defined your own String class in your module), however the mechanism in which the *selector* is resolved to a method is smart enough to choose the correct method based on the context (module) in which the message was sent.
This is why I said that this would require deep modifications to the message dispatch mechanism and to method dictionaries. However, it's not impossible, it probably needs to be prototyped in the image before expending the effort to change the VM (which will ultimately be needed if a solution that performs well is desired). Also, such a change in the dispatch mechanism of the VM may adversely affect the performance of Squeak overall, but hopefully the impact can be made small enough that the trade off is well worth it.
Also, there is a real life analogy that can be made. When you are sent messages from people in real life, you are likely to respond in different ways depending on who is sending the message...you may even respond more or less promptly depending on the sender (my wife gets a very high priority response...most times ;)).
Finally, having such a mechanism in place may ultimately allow us to reconcile the benefits of a Morphic all in one design vs. an MVC keep everything separate. With such a mechanism, a GUI module that depends on a Morphic module could add Morphic methods to a BankAccount without affecting (or intermixing) with the domain Behavior that the BankAccount domain module creates. (We may need to expand the scope to allow modules to add instance variables in addition to methods however). But, let's take it one step at a time...there are likely to be a lot of people that label me a heretic based on this final comment (due to the almost religious status that MVC has achieved)...but I'd love to have a system where this sort of thing could be experimented with.
- Stephen
P.S. Dave Simmons was mentioned as an authority on this subject...does he have any papers on web about this topic?