BACKWARD vs FORWARD compatibility when adding a required Avro field without default under zero-downtime deployment

Context

A team must add a required field to an Avro schema used by Kafka producers and consumers. The deployment must be zero-downtime: producers and consumers cannot be upgraded in a coordinated cutover. Confluent Schema Registry enforces compatibility at registration time, and the default TRANSITIVE validates against all prior versions.

Constraint

The new field cannot have a default value because business logic requires explicit producer input. BACKWARD compatibility (consumers upgraded first) fails because old records lack the field, causing deserialization errors in new consumers. FORWARD compatibility (producers upgraded first) fails because old producers cannot serialize records that satisfy the new required field. FULL (BACKWARD+FORWARD) rejects the change outright.

Documented Workaround

The two-step pattern — first add the field as optional with a default (compatible both ways), deploy all consumers, then make the field required in a second schema change (BACKWARD only) — is widely documented but doubles registry entries and relies on operational discipline to complete the second step.

Questions

1. When the intermediate optional-with-default schema is registered under FULL compatibility, does the subsequent required-field registration pass TRANSITIVE validation against the original schema, or must compatibility be relaxed temporarily?
2. If Kafka Streams state stores use the same subject, does the two-step evolution require state restoration or re-partitioning between steps?
3. Are there documented cases where Protobuf or JSON Schema in the same registry exhibit different required-field semantics that would alter this trade-off?