RabbitMQ rollback limits after an upgrade: what can definitions export actually restore?

We are planning an in-place RabbitMQ upgrade and need a rollback plan before we proceed. From the documentation, a node whose data directory has been migrated by a newer version cannot simply be downgraded, and many feature flags cannot be disabled once enabled. So a binary rollback of the same cluster appears to be off the table.

Our current thinking is to rely on a definitions export (vhosts, users, permissions, exchanges, queues, bindings, policies) taken before the upgrade, and rebuild on a fresh cluster running the old version if the upgrade goes wrong. What is unclear is where the real limits of that approach are.

Specifically, definitions export does not carry message payloads or quorum queue replicated state, so any durable messages sitting in the old cluster at rollback time seem unprotected. Blue/green cutover solves topology but apparently not in-flight data.

Questions:

• Is definitions export plus a fresh old-version cluster the documented ceiling for rollback, or is there any supported way to preserve messages stored before the upgrade?
• Are there feature flags or schema changes in recent versions that make even a definitions-based rebuild on the old version impossible?
• Does stopping the node before snapshotting the data directory change what can be safely restored?