We regularly use postscripts and noticed they are still running when app installs or updates fail. We only want the postscript running if the app install or update completes successfully. We regularly update information in the uninstall key in our post scripts if the vendor doesn't by default (i.e. - installdate, source, etc.) as we want that inventory and now it is writing this info to the registry even when it fails which we obviously do not want.
Forgot to add: with the ability to set custom return codes, it would also be useful if such a feature would consume the return codes list as defined in the Publisher -- and not just expect 0 and 3010 to be the only success codes. So the post-(un)installation script could be launched on any defined success codes, and skipped on failure or unknown return codes.
Another case for this would be for a post-uninstallation script that does additional cleanup (i.e. remnant files deletion, registry key removal, etc.). If the main uninstallation program fails, one would probably not want for the cleanup to happen.
Being able to set the post-(un)installation script's behavior when encountering a failure would be more user-friendly than having to pass the return code as an argument to the post-script, and adapt the post-script to react in accordance with the return code (i.e. continue and Do-Something if RC is success, but exit prematurely if RC is failure).