nTimeLock does the reverse. It's an open transaction that can be replaced with new versions until the deadline. It can't be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn't enabled or used yet, but the support is there so it could be implemented later.
Does using nTimeLock also tie up some of the sender's coins until the lock expires? I imagine that it would have to, and that would solve the escrow problem immediately, allowing the sender to effectively write the Bitcoin version of a backdated check. Even better, seeing the locked transaction on the network would allow the merchant to know that the sender actually does have the funds to buy the product, and if the coins are tied up until the lock expires, that the sender will probably
still have those same funds. The possibility of a fraudster sending a locked transaction to buy something online, and then revoking the transaction after the product has been shipped, still exists. But it can add confidence in a transaction without requiring a third party escrow. Would the revocation of transactions leave a record inside or outside the blockchain? If it did, a scan of the blockchain might be able to highlight increased risks of a revoked transaction if a fraudster had already done the scam once to someone else with the same set of coins. Doing this would temporarily 'taint' the coins used in the revoked transaction, until they were used in several valid transactions.