This whole thing leaves a bad taste in my mouth as this was discussed at length 18 months ago with all the relevant stakeholders agreeing. Not blaming anyone, just sad to see that something this low on impact and this high in return would miss the 2022 slot.
The quoted part from Mark is something I agree with; its a technical nightmare for wallets should this not be done WELL in front of any transaction format change.
To roll out both the restriction-of-version-number and the actual new tx format at the same time means you need to push the entire ecosystem an update that says “NOW you can trust the version number, and a version N has to be routed to different code”.
That is literally a nightmare scenario.
The alternative, as Mark also said, means that those pieces of code should know more context that they currently don’t need or have, most places that parse transactions are at best SPV and can’t do something like “MTP”.
Both scenarios make the amount of work needed to introduce a new tx format a lot harder and a lot more fragile in the months between release of such software and actual BCH upgrade. The solution to do the version number requirement first means that such software deployments completely eliminate this complexity as they can be certain that a tx of version NEW is going to be in the new format.
A self-contained transaction that without context can be judged to be well-formed is a pretty useful thing for software developers.
If the people in charge would be suggesting now that in 2023 an incompatible transaction format is going to be activated and no version safety exists until that same day, then I fear a lot of libraries will not get written or released as the foundation is too unstable to build on. Its just too hard to do so correctly.