It seems like there are three ways someone may want to use transactions/locktime

1. Send a transaction with locktime and revoke or change it before the lock time
2. Send a transaction with locktime and be unable to change it, yet the party receiving the transaction can still not spend it until locktime
3. Send a transaction and shortcut the locktime (basically a normal transaction, described below with uint_max)

So reading this thread I understand transactions aren't in blocks until they are final / locktime expires (unless unit_max), but I'm thinking more theoretically for a second on how it should/could work.

So usecase #1 seems covered today, I'm told you can resend transactions without the lock time or with a new version and other miners will confirm this (correct me if I'm wrong)
And usecase #3 is basically a normal transaction without locktime.

The interesting usecase is #2 I think. Here are a few problems I see...

Right now nodes probably wont relay transactions with a future locktime of n days out, forcing the party creating the transaction to resend the transaction closer to the locktime or give the transaction to the receiving party to retransmit. Possible solution to this problem is include the transaction in the blockchain, it would be not be able to be changed but that is the purposes of usecase #2.

Because the transaction is not confirmed until the future locktime, the sending party can create another transaction and mine a block their-selves (or ask someone else to) and reverse a transaction with a future locktime. The only way around this I see is to add future transactions to the blockchain.

So if you did add the transaction to the blockchain then your problem is how do you prevent the receiving party of the transaction from spending the coins before locktime. Though this seems like a easier problem than trying to solve the above two problems. Is it not possible to check the parent transaction of a newly created transaction to make sure it is valid at the time of the new transaction?

Again I (think I) realize how it works today, but I dont think this usecase #2 is covered today (please correct me if i'm wrong). Assuming #2 isn't covered today, would adding future transactions to the blockchain, and verifying the parent transaction's locktime be possible? Or does that break all kinds of other things I'm not thinking about.

Thanks