I'm not really keen on speculating about what senderLastMod means, and you don't seem inclined to tell me. Hopefully this means that you've solved some really hairy problems in distributed computing and are too busy writing your system to explain how it all works.
More likely, you think that you can use either the index of the latest version of the ledger or a per-address sequence of some sort as the nonce that protects your signature. Both of these options have big problems in the real world.
You seem like a smug little prick. Either you came by that bearing honestly, in which case I don't need to tell you where this scheme falls apart, or you are talking about things you don't really understand, in which case I don't want to tell you.
I suspect the second, so I'll conclude with a hint. "transaction rate vs. convergence"
I thought it was fairly obvious, but yes it is some kind of per account sequence. Could be simple counter, but this forces to keep empty accounts forever. Hash of block which include last spend operation from sender account would be better. You can safely emit multiple concurrent tx. If all are included in same block then all are valid. If some of them were left you just rebroadcast them with updated sequence.
It can be current best block hash and network could accept such tx in any of let say next 100 blocks. Network would discard duplicate tx in 100 blocks window so replaying would still be disallowed. There are multiple valid solutions.
I'm really asking honestly, but just don't like your arrogant tone and one liner replies without any arguments but always negative and invoking some kind of secret knowledge I should already know about.
So last time: why keeping per account sequence gives you a lot of real world problems? You guarantee uniqueness of all transactions this way and I don't see why this should any worse than bitcoin. Please show me how to exploit such system. If you don't want to tell me it's fine, just stop pointless attacks.