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,