[PEAK] Method replacement and ambiguity resolution using next_method

[P.J. Eby]

Here's an idea for making it easier to replace existing methods 
without using a priority or "replace" keyword, and that doesn't 
result in an ambiguity error.

Suppose that two methods have the same or overlapping signatures, and 
the one that was added *second* has a "next_method" argument.

Then, in that case, we could perhaps assume that the second method 
was written with the anticipation of it overlapping some other 
case...  and go ahead and treat it as having higher precedence.

However, if the second method does *not* have a "next_method" 
argument, then we can assume that the overlap is unintentional, and 
therefore worthy of an AmbiguousMethods error.

In a sense, this is akin to the logic of Before and After methods: 
they are allowed to be ambiguous, because they're all going to get 
called anyway, and so we resolve the ambiguity by method definition order.

So, in this case, we're saying that if you *can* call the method 
you'd otherwise be ambiguous with, then we'll resolve the ambiguity 
in favor of the most-recently-defined method.

The main potential downside is that we might lose ambiguity warnings 
in cases where next_method() is never actually called, and the 
overlap is partial and accidental.  It's also possible that people 
might go around including next_method everywhere, even if they never 
use it...  and thereby end up hiding ambiguities.

However, at least currently, it seems like use of "next_method" is 
rare, so these cases are unlikely to be hidden.

Your thoughts?