You can think of the current method resolution like this:

(1) send the types to the metaclass and have it figure out what method to invoke.

With the first proposal, this becomes:

(2) if (types & metaclass are as expected) { call associated method } else { send the types to the metaclass and have it figure out what method to invoke. }

The question is: if the programmer says they expect certain types & metaclass, but at runtime we find something different, is that an error?

(4) call associated method

Of course, you'd only want to turn off the type checks after you've thoroughly debugged, profiled, and found them to be a bottleneck. (I don't understand why Java even has a switch to turn off all assertions globally; turning off the ones that aren't a bottleneck can only lead to confusing messages or even corrupt data. And it really boggles my mind that they're off by default. Oh well.)

Option (2) is essentially what call site caching does, where "expected" is what was seen last time. But it doesn't allow (3) or (4). Whether that's a problem or an advantage depends on your point of view. ;)