Is the following suggestion a solution to that?
The position of a transaction in the blockchain should define which version of the rules is applicable to it
What keeps us from using the old way of calculating a txid for transactions in prefork-blocks and the new way after the fork?
Unconfirmed transactions are the issue. What do we do about transactions that were created just before the fork block? How do you distinguish between an unconfirmed transaction created prior to the fork and an unconfirmed transaction created after the fork block?
Also, Tyler Nolan has a similar suggestion:
One example gmaxwell gives: all presigned nlocktime transactions would be broken. For users keeping these in storage they may well represent a lot of security. Gone... the moment a new version of the software no longer sees the transaction as being valid.
The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid.You could have a rule that you can refer to inputs using either txid or normalized-txid. That maintains backwards compatibility. The problem is that you need twice the lookup table size. You need to store both the txid to transaction lookup and the n-txid to transaction lookup.
The rule could be changed so that transactions starting at version 2 using n-txid and version 1 transactions use txid. This means that each transaction only needs 1 lookup entry depending on its version number. If transaction 1 transactions cannot spend outputs from transaction 2 transactions, then the network will eventually update over time. It is still a hard-fork though.
Is that applicable / workable?
The first is possible but it is not optimal because it requires twice the lookup table size.
The second is also possible but the issue is the hard fork. The problem is that hard forks shouldn't be done often and for small things like this. It would be better if it was packaged with other stuff that is desired that also requires a hard fork. If also has less functionality than segwit.