Tomcat rollback after a failed upgrade: symlink switch or in-place reinstall — what are the limits?

We maintain several Tomcat 9 instances and are planning a move to Tomcat 10.1. Using the documented CATALINA_HOME/CATALINA_BASE split, our binaries live in versioned directories while conf/, logs/, and webapps/ sit in a separate CATALINA_BASE, so in theory a failed upgrade should be recoverable without touching instance configuration.

The unresolved decision is the rollback mechanism itself. One option is keeping the previous Tomcat directory intact and repointing a symlink (and the systemd unit's CATALINA_HOME) back to the old release. The other is reinstalling the old version in place over the failed one. Each seems to have different implications for systemd unit definitions, file permissions, and our audit trail of which binary served which deployment.

We also know the jakarta.* namespace migration means rollback must include redeploying the original javax.* WARs, and that work/ and temp/ caches are version-specific.

Does the symlink approach have any documented limits when systemd units hardcode paths? Is reinstalling in place ever preferable for auditability? And must expanded WAR directories be cleared on rollback, or only the JSP compilation cache?