Zod validation errors persist after breaking tRPC schema change

The goal is to decide whether tRPC should supply a built‑in mechanism that safely handles mutations that fail validation after a breaking schema change, allowing automatic rollback or deferral without requiring manual versioning.

Currently tRPC validates incoming data with Zod schemas on the server. When the server schema is altered in a breaking way while clients retain the old type definitions, validation errors are returned and no automatic rollback occurs. Developers must implement versioning or keep changes additive themselves, and the documentation does not prescribe a standard rollback procedure for mutations that have already been executed.

It remains unresolved whether a first‑class versioned endpoint or middleware would be appropriate, and how such a feature would interact with mutation execution guarantees and client‑side type safety.

Should tRPC introduce a versioned endpoint mechanism for automatic client‑side schema negotiation? What middleware patterns could safely rollback or defer mutations when a Zod validation failure is detected? How would this feature coexist with existing mutation guarantees?