...

Once the downgrade snapshot has been loaded by all nodes, a software downgrade is now possible. In both lossy and lossless downgrade scenarios, there may be tagged fields present in the metadata records from previous newer version, but these are transparently skipped over during record deserialization.  

Metadata Version Change Implementation

Although it falls under the heading of implementation rather than public API, it is worth saying a few words about the implementation of metadata version changes here.

When the MetadataLoader code encounters a metadata version change record:

1. We will write a snapshot to disk at the offset right before the metadata version change.
2. We will serialize the in-memory state to a series of records at the new metadata version.
3. We will publish the in-memory state at the new metadata version.

Importantly, this relies on the property that MetadataDelta only contains changes. So if a specific topic doesn't change during a transition from one metadata version to another, it should not be present in MetadataDelta. This will make performance proportional to what has changed, rather than the overall size of the metadata.

There are several reasons why we prefer to do it this way: 

1. In the case of downgrades, it would be quite difficult to maintain correct code for iterating over the entire in-memory state and altering things so that only the data present at a given MV remained. This code would probably end up looking a lot like a metadata image save and load anyway.
2. This tests the implementation of "hot snapshot loading" (that is, loading over an existing snapshot), a code path that otherwise does not receive much testing.

Compatibility, Deprecation, and Migration Plan

...