I don’t think you are missing anything.
One thing you might take a look at is the liquibase status command. The documentation says it will give you a count of unrun changesets, or a list of unrun changesets with the --verbose option. I don’t know if it will list “extra” changesets (this would be changesets that are marked as applied in the DATABASECHANGELOG table, but that do not exist in the changelog.xml). If it does show the ‘extra’ changesets, you could use that as an indication that rollback might be necessary.
In that case, you would need to have a workflow where the changelog is packaged with the application, so that when you shipped version 2.0 of the app, it had version 2.0 of the changelog, and version 2.1 of the app had version 2.1 of the changelog. If you roll back the app from 2.1 to 2.0 by just re-installing app 2.0, you might be able to tell using the status command that a rollback of the database was necessary (the db changes for 2.1 would be in the DATABASECHANGELOG table, but not mentioned in the 2.0 changelog) but you would still need the 2.1 changelog (with any custom rollback tags required for the 2.1 ‘go forward changes’) in order to safely roll back the database from 2.1 to 2.0.
Hope this helps,
Principal Software Engineer
Datical, Inc. http://www.datical.com/