Schema validation failure during Nomad job rollback after server upgrade

Goal: Guarantee that a Nomad job can be rolled back to a previously stored specification without encountering schema validation errors after the Nomad server cluster has been upgraded to a newer version that introduced additional fields.

Constraint: The `nomad job rollback` command restores the exact job specification persisted in the Raft state, which may contain fields that are unknown to an older server version if the rollback target predates the upgrade. Nomad does not automatically downgrade or strip those unsupported fields, so the success of the rollback depends on the server’s ability to accept the spec as‑is.

Uncertainty: Whether Nomad should implement schema‑aware rollback that removes or transforms incompatible fields, or whether it should leave the responsibility to operators to pre‑validate or edit the spec before rolling back.

Questions: Should Nomad automatically strip unsupported fields during a rollback to an older server version? Is it sufficient to rely on operator‑driven pre‑validation and manual spec adjustment? What behavior would best balance safety and operational simplicity?