...

For this change specifically, all features rely on at least MV 3.3-IV0 (since this enables the writing of features to the metadata topic as per KIP-584). Any command to try to set a feature (either via storage or upgrade tool) when metadata version is below 3.3-IV0 will fail. (If an RPC is sent, it will also fail as the version is not supported)

A Note on Feature Interdependence for the Features in this KIP

Transaction version 1 will include the flexible fields in the transaction state log, and transaction version 2 will include the changes to the transactional protocol as described by KIP-890 (epoch bumps and implicit add partitions.) Transaction version does not rely on any other components, so as long as metadata is 3.3-IV0, there are no failures. 

Group coordinator version will be used to specify which version of the group coordinator is used. The first use case will be KIP-848. We will use version 2 1 of the flag to gate all the new records and the new consumer group APIs (Heartbeat, OffsetFetch, OffsetCommit, ConsumerGroupDescribe and ListGroup requests) present in AK 3.8. So version 1 0 will be the only the old protocol and version 2 1 will be the currently implemented new protocol. For these versions, there are no dependencies on the metadata version . The changes are orthogonal.other than the need for the feature records like transaction protocol version. 

For both features, we will be finally using the flexible fields in KIP-915. This means that the records for the state topics of the transaction coordinator and the group coordinator will be determined by their respective feature versions and not metadata version. 

Test Plan

Tests will be added to the StorageToolTest and FeatureCommandTest.

...