I have a concept for per-input timelocks and reorg safety that would trigger that, for what it’s worth: namely “any input can present an annex entry that commits to height || bytes; if there is not a prior block at height height whose hash ends with bytes, the tx is invalid”. Presuming the script could access that annex entry, it could check that bytes is 32B long, then check for a 48B+32B value that hashes to it, then use the 32B value as the tx merkle root.
The “normal” use of that annex entry would be either as a per-input timelock (0-length bytes), so that presigned spends that use variable timelocks could be combined into a single tx (HTLC spends?), to prevent signet/testnet signatures being replayed on mainnet (commit to the last byte of block 1), to fork coins in a hardfork scenario (BCH’s block 478559 ends in ec, BTC’s ends in 48), or (perhaps) to invalidate a tx should a reorg occur (you refund 0.5 BTC due to a mistaken payment, but the refund doesn’t actually spend the payment txo, perhaps because that was already spent for some other reason, so you commit to the last 4 bytes of a subsequent block’s hash effectively increasing the PoW required to replace it by 4B times). I say “perhaps” in the last case, because I could at least imagine this having an “implies a timelock of height+100 blocks” restriction which would make that usecase not very useful.