Does release_handler:rollback/1 guarantee consistency after a failed OTP upgrade?

Goal

Determine whether release_handler:rollback/1 can safely return a running Erlang node to the previous release after an upgrade fails partway through activation.

Constraints and uncertainty

Assuming a standard OTP release with release_handler and relup support, the upgrade may already have loaded new modules and migrated some processes while other nodes or processes still run the old code. Documentation indicates rollback is manual and requires the prior release to remain available, but it does not specify what happens to process state already transformed by code_change/3, or to shared resources such as ETS tables and files rewritten by the new release.

Specific questions:

• Does release_handler:rollback/1 revert every process to the old code version, or only processes that have not yet completed the code change?
• What conditions must hold for the system to be considered consistent enough for rollback to proceed?
• If the new release mutated shared state before failing, is rollback sufficient to restore that state, or must the application compensate manually?