ghc compiler in Haskell has -fdefer-type-errors flag. SBCL Common Lisp implementation has option to turn type warnings into errors. Extending -fdefer-type-errors function and creating better type checker for dynamic languages could achieve best of both worlds.
Some things like overloading based on return values don't work dynamically, but you could either choose to not have them or resolve them in development time. I would like to see languages where dynamic vs. static is continuum and programmers can determine how much they need want case by case basis.
But then you lose the ability to freely mix and match the static and dynamic code. For example, if you want to write a dynamic implementation for some parametrically polymorphic code there must be a way to check at runtime that the dynamic implementation is respecting the type that you assigned to it (there are ways to do that but they are all very tricky).
The list of tricky things also grows very quickly once you put some though into it. You mentioned return type polymorphism but there are also many other things that are hard to check dynamically (record field names) and lots of things that dynamic codes likes to do (like mutability and subtyping) that force extra complexity into the static type system or that can be used to subvert the static types if you are not careful.
It's relatively easy to do this statically compared to bringing the benefits of Haskell to a unityped language. We just don't program in languages designed around dependent types typically.
Dependent types aren't hard.
Agda, Idris, Coq for any who are curious as to what that looks like.
Total functional programming is cool ^_^
For a language that truly hass optional static types see Shen[1]