I am aware of CSV and that wasn't what I was thinking. In retrospect, I should have used different terms.
What was supposed to happen was that sequence numbers would allow replacement, but it was never implemented and isn't secure anyway.
It would give much more finely grained sequence numbering and closer to the original intention. I don't see it as a replacement for CSV. In fact, CSV or locktime could be used to make sure later versions of the transaction have time to be broadcast.
The desired operation is that each fully signed transaction could act as a link in a chain. It would count as a valid transaction conditional on it being built on a link with a lower sequence number (or the anchor/root of the chain). This means that there is no point in broadcasting anything but the last version, since if you broadcast an earlier version and it gets into a block, one of the other parties will just broadcast a later version.
I was thinking about multi-party versions of payment channels. Lightning is inherently based on linking up lots of 2 party channels. This means that a hub must spend capital on each channel being maintained.
In principle, the hub could create an N party channel with a single capital deposit and share it between the customers. Even in the simple case, where all the customers have 100% uptime and always sign state transitions that don't reduce their allocation, there isn't an easy way to do it.
Penalties based on revoke codes don't work as well with a multi-party channel. In a 2 party channel, you simply send 100% of the channel's funds to the compliant party. With a multi-party channel, that doesn't work.
The original two-way channel would work. You could start with a locktime 60 days in the future and then step it back 2 hours for each transition. All parties would have to sign the new transaction though. It would be better if the signature from parties that aren't having their allocation reduced wasn't needed.