I think "don't break anyone's code" > "break code but tell user about" > "silently break code".
Rich Hickey has very strong feelings about breaking other people's code, and I tend to agree with him about: don't do it. Breaking other people's code is mean and unnecessary.
I don't disagree, except to say that "don't break anyone's code" is a bit better than "break in a way that the compiler catches and helps you fix", which is a GREAT deal better than "silently break code".
Paranoia about breaking code makes sense in languages that have few mechanisms for aiding in refactoring. It makes less sense when the language is acting as your teammate.
I'm an outsider of Elm community, but from my perspective, breaking changes in Elm 0.19 is still a pretty big deal where lots of people complain about.
Talking about refactoring, I think it's much easier when you are working with a codebase that built by composing lots of small pure functions together. The place where it gets tricky is the part with side-effects where you have to carefully test it either manual or automate anyway. Type error will likely to be caught during that process. With Clojure Repl, we can test that out pretty quickly.
Elm’s 0.19 update was not super-well handled because it had quite a few breaks that are not easily handled (removing all custom operators, which make certain code structures different, disallowing Debug in packages where the new (arguably correct) way requires restructuring, etc.) Just introducing Maybes in a function parameters or removing them in return types would have been quite painless, I think.
Rich Hickey has very strong feelings about breaking other people's code, and I tend to agree with him about: don't do it. Breaking other people's code is mean and unnecessary.