On reflection, I don’t personally think this is a good idea. Ultimately, we do not want to have multiple metadata standards. The goal is always that tools produce and consume the latest standard, with all of the features implemented and present.
Any problems caused by tools wanting to adopt features from later standards before earlier ones are purely transitional, and in practice indicate that we’re changing standards too fast, and not allowing tools time to keep up. So rather than adding complexity to the standards to allow tools to “opt in” to features bit by bit, we should probably be helping projects implement the standards as they are.
While I understand that this has the potential to cause problems for people proposing new metadata fields, it should mostly be minor, as we rarely, if ever, add mandatory fields. The case of “Dynamic” is unusual, because version 2.2 assigned a meaning to not having any fields marked as “Dynamic”, which is not 100% backward compatible. I made a mistake there, as I should have noted the issue in the “Backward Compatibility” section of the PEP. For future metadata PEPs, I would suggest they learn from this and make sure that the backward compatibility section addresses the question “If a project updates the metadata version, but makes no other change, is the meaning of the metadata the same? And if not, then is that an issue?”