As for the invocants being in in different classes, that is indeed what I suggested. Like LWP does with the LWP::Protocol::* classes. This solution has pros and cons, with the need for appropriate classes to exist being one of the cons. But if we're going to rule out a design technique because it requires us to create a few extra classes, then we would never use MVC. Sometimes it is not worth adding classes, but if it makes sense, don't hesitate.

Speaking of MVC, Dan Sugalski's prolems seems to me to be one that you can solve with an MVC design. In fact people happily do so in languages like Smalltalk and Ruby. Yes, it does mean designs with some extra redispatching. I don't consider that a major flaw.

As for your Some::Parser example, I grant that a direct class-based dispatch doesn't work there. However it is trivial to extend it in ways where a direct MMD dispatch won't work either. For instance suppose that you're parsing any of several related formats and need custom logic to autodetect which format you've been presented with. If you're getting that specialized, it makes sense to me to have customized dispatch logic. Not every facility needs to be built into the language, and people have been writing parsers with customizable behaviour since before either of us started programming.

I agree with you about interfaces being more important than types and classes. And that's one of the reasons that I have no problem writing small helper classes whose job is to do the translation so that different kinds of things can present the interface that you want.

And I should point out that you did use the getter/setter example. I direct you to your implementation of name in The beauty of MMD.