So, probably time to start with a series of posts describing the changes for 3.2. Exec is first.
There is not so much about exec, really. 3.1.4 brought one new bug into exec, namely the Alert AN_BadFreeAdr, which was triggered on a bad memory release, forgot to restore one register and hence caused another crash afterwards. This was fixed by SetPatch of 3.1.4.1, and now the fix was migrated into the code.
There is another series of fixes, though of old bugs. Alert() in general had a series of problems. First, it did not save all registers. Thus, in case ROMWack was entered later on, the register file was partially overwritten and thus made a post-mortem debug with ROMWack rather pointless. Also, ROMWack tried to detect the CPU type - by the same function exec uses during bootstrap. This sounds fine, but it is customary these days to move the vector base register out of the zero-page, and this is something the mentioned CPU-detection algorithm did not expect - it rather moved it back. Sometimes with fatal side effects. The code is now more careful in not touching VBR if it does not have to. The problem of the lost registers must have been introduced somewhere in the v37 series because the 1.2 kickstart did better.
Unfortunately, this is not sufficient to make ROMWack happy because there is another way how to enter it - namely through the dos.library "Alert" requester. ("Software error - task held..."). Unfortunately, this requester *also* overwrote the registers, and it neither saved the stackframe of the crash. The latter is, however, important to be able to debug a crash with the ROMWack. Thus, the dos.library exception vector - aka the error requester - was improved by saving all registers, and by also making a copy of the exception stack frame. If the user presses "cancel", the stack frame and the registers are restored, and the code enters the default exec error handler, which again points by default to the ROMWack.
Thus, ROMWack should have been become a lot more useful than before as it has access to the important registers and the stack frame causing the problem.
Or, use a debugger in first place...
There is much more to be said about the dos.library, but this is for a later episode.