The transaction-version field in the transaction object has at this time no consensus rule on its correctness.
The transaction version has mostly been kept unused and the version of an incoming transaction has not had much of an effect on selection of code-paths.
Should in the future we decide to introduce a new transaction format, deciding how to parse in incoming transaction will best be done based on the transaction version. At such a time it then would be required to reject transactions that are advertising the wrong transaction number.
To allow for less complex software during such a transition it will be highly beneficial to ensure correct transaction versioning earlier.
The new rule does not restrict transactions that currently comply with the standardness rules. As a result the only change would be in full nodes and specifically the block-validation technology.
The impact on the rest of the ecosystem is expected to be zero.
This is a tightening of allowed transactions in a block and therefore can be a soft-fork. Author(s) recommend this to be scheduled for a future protocol upgrade.
Transactions choose their version based on capabilties and, in future, on how the transaction is structured. Transactions shall state in the version field the correct version for that choice. At the time of writing this CHIP that limits the allowed version numbers to 1 or 2.
