Agreed, the haskell / rust overloading where there's a loosely enforced[^1] but implied contract is probably the best of both worlds.
But even without strong constraints, the language's culture is a huge aspect of whether it becomes a problem or not. For example, in python, the language has almost[^2] no constraints on overloading, but people generally use it in very reasonable ways.
[^1] the typeclass/trait has an interface that is enforced, but there's usually also some implied laws that the type checker can't verify for you
[^2] the big exception being comparison methods like `__leq__` which throw a runtime error if the result isn't a boolean, much to the consternation of DSL writers
But even without strong constraints, the language's culture is a huge aspect of whether it becomes a problem or not. For example, in python, the language has almost[^2] no constraints on overloading, but people generally use it in very reasonable ways.
[^1] the typeclass/trait has an interface that is enforced, but there's usually also some implied laws that the type checker can't verify for you
[^2] the big exception being comparison methods like `__leq__` which throw a runtime error if the result isn't a boolean, much to the consternation of DSL writers