This might not be possible because your notion of a justified change may not align with other people's. IIRC the removal of the Show constraint on Num was driven by type level natural numbers? which matter to the type hackers but not to someone whose main concern is getting an unmaintained web interface running. (OTOH it also may not have any effect on said web server, since it mostly affected people who take the somewhat risky action of defining their own Num instances; I suspect the exceptions change would have more impact on web stuff.)

As for the exceptions stuff, that was a multi-step change. Exception handling was somewhat unprincipled and came in two forms, which used the same function names but in different ways. There was support for IO exceptions in the Prelude and conflicting support for general exceptions, which behaved somewhat differently when handed an IO exception, in Control.Exception. One key behavior was that you had to handle all exceptions or none at all; the only way to choose specific exceptions was to handle all of them, inspect the exception object, and rethrow if it wasn't one you wanted to handle. And inspecting the exception object to see what it had in it could be tricky at times, because there wasn't much guidance with respect to user defined exceptions and some library exceptions did things slightly differently from the ones in the base.

The exception cleanup made IO exceptions and other exceptions behave consistently and got rid of the conflicting definitions. This did require source changes, as anyone relying on the Prelude exceptions had to add an import of Control.Exception and anyone using old-style exceptions generally had to add a type annotation to their handler; more ideally, they'd rewrite their exception code to handle specific exceptions or exception classes instead of poking at the exception object to determine whether it was one they cared about or not --- but this was not necessary to get older code running again, only the added type annotation was necessary.