This is not hard to understand: under usual semantics for function calls it is clearly impossible to do return type overloading in a dynamically typed language. But, as I pointed out above, it is perfectly practical to cheat and provide an indication of the desired return type as an extra hidden argument to every function call (this is what Perl does with wantarray: it is a "builtin function" but the effect is really that of an extra boolean parameter to every function call that specifies whether the result should be an array or not).
Ok, this much I understand, but I wouldn't call this overloading on return type... It's - clearly - overloading on input type, either implicit (wantarray - I checked the docs, it seems to be a variable set automaticaly depending on context by the interpreter) or explicit, but input type nevertheless.
So, the short answer is - as I thought previously - that no, you can't have implicit dispatch on return type in dynamically typed language.
Contracts are probably getting close, but you still need a version of apply that will get expected return type and a bunch of functions to introspect (or a macro that would do the same, but let's not wander there, as lispy macro systems are equivalent with static type systems anyway).
And you can generalize from wantarray's Boolean to a more general parameter indicating required return type.
It gets harder and harder though, to provide information about more and more distant parts of the program in a dynamically typed (or untyped) environment.
From what I've heard, Racket's contract system is another interesting attempt to provide something that's typically done in a static setting---the benefits of dependent typing---in a dynamic one.
