I am a bit confused by this. Typically when you make a breaking change it is because the call site has to make a new sort of decision so you may not want all calls to be refactored the same way and there is no way of determining which you want at runtime.

The example the author uses is modifying a function to return an int or null instead of an int. Let's say you implemented the function a bit naively and in the null case your function would crash the program. Now you are going to refactor your codebase so the caller gets to decide what happens in the null case. Some callers may be unable to handle the situation and will need to implement the crash/exception some may use some sort of fallback behavior.

I think haskell's type system probably would probably prevent someone from having the issue I described above but the problem still stands. Let's say you had a function that returns a union type and you have areas in the code that are supposed to handle every case of that type. If you had a case you need to handle it everywhere and the compiler can't know how you want to handle it. A lot of type systems will catch the missing case which is awesome but you still need to handle each one.