Atomic upgrade rollback behavior when /var contains application state

Atomic Fedora upgrades via rpm-ostree preserve the /var directory across deployments, but this creates uncertainty about rollback safety for stateful applications.

Fedora Silverblue, Kinoite, and Fedora IoT use rpm-ostree for atomic upgrades that compose new OSTree filesystem trees without touching the running system until reboot. This design ensures interrupted or retried upgrades cannot leave a half-written root filesystem, and re-running an upgrade is idempotent since the same commit is reused rather than duplicated.

Deployments are stored as boot entries, allowing rollback via bootloader selection or 'rpm-ostree rollback'. However, this command restores the OS tree but does not revert /var or /home, meaning application-level data migrations or state changes persist across rollbacks. The three-way merge for /etc can also leave .rpmnew conflicts for heavily customized configurations.

The core question is whether the atomic upgrade mechanism provides sufficient isolation for applications that maintain critical state in /var, given that rollback does not revert this data. What specific behaviors or configurations are needed to ensure application state consistency when rolling back between deployments?