That is sort of the function of the Change to API Behaviour and API Addition checks - changes to a core API might be one way to fix those, but external package might be a better way, especially if the core API is arguably not broken in the first place.
This one is a good example of that; is not allowing 4. to parse as an Int a bug or a feature?
deadEndsToString would be fine in an external package, if it were not for the fact that it already exists in elm/parser and throws a runtime exception. Fixing it in an external package would still leave that broken code in place.
But yes, good idea, I will add a column for Fixable in Non-Core Package.