> does exactly what you're saying (unlocks a behavior after a specific time)
I'm sorry, I see that the phrase "time-unlock" might be a bit misleading and I also misspoke when I said "we don't have a way to unlock some behavior after some time". I actually meant that we don't have a way to *lock* some behavior after some time. I meant to describe is a (currently non-existent) opcode that would allow a spend-path to remain unlocked for a period of time (just as a time-lock locks a spend path for a period of time). So after the specified block (or relative number of blocks), the spend path would no longer be useable. This "time-unlock" opcode might be better named something like op_invalidafter, op_validbefore, or op_isbefore.
This opcode would allow ownership of an output to "switch over" from one owner to another at a specified time. Before that switch over time, there could be various ways to "reverse" the transaction by spending the output. Correct me if I'm wrong, but I don't believe this is possible with current bitcoin opcodes.
The only way to lock a behavior is to spend the funds to a new UTXO. In Bitcoin we don't do this at the script level because we want script authorization to be context-free and monotonic. E.g., if something is true, it should always be true. At the transaction level, you can remove a spending path one by one. This is kinda what CTV is doing fundamentally.