Using these opcodes I can make an output that can *only* be spent with another output -- e.g.,
<s> <n> OP_CISV OP_DROP <pk> OP_CHECKSIGVERIFY
<h, i> <n> OP_CIOV OP_DROP <pk> OP_CHECKSIGVERIFY
Let's look at CISV first:
1) Assume that <s> is from the same owner as PK
2) Assume that <s> is from a different owner than PK
In case 1, the wallet can create or recreate the appropriate output as needed if it gets spent/stuck
In case 2, the wallet can get "frozen" in a reorg until a signer on <s> re-spends.
For CIOV:
1) Assume that <h, i> exists in the chain somewhere
2) Assume that <h, i> exists in the mempool somewhere
3) Assume that <h, i> does not exist (or, is provably non-creatable -- h = txid(x) | x.IsValid() == false)
In case 2, this is just a fancy op-return.
Case 1 degrades into case 2 in the event of a reorg.
In Case 2, if the output <h, i> is spent in another transaction, our script becomes provably unspendable (unless a second reorg).
Otherwise, it is possible to mine a block with our transaction.
Compare the above to normal transactions:
1) If a reorg occurs, and someone double-spends, your transaction gets cancelled.
2) You can re-sign your UTXO onto a different transaction
However, if you have deleted your key (e.g. using a pre-signing HSM), or your transaction was using a multi-sig with an uncooperating party, you will have an output that may be effectively burned.
These issues are -- as with CTV -- not present in the single input use case.
Thus I argue that CTV -- whose semantics are less powerful/flexible than CISV/CIOV -- aren't introducing something that's not already present when doing protocols involving more than one input.
Further, on CTV "monotonic authorization":
Generally we want Bitcoin Scripts to have the property that once a condition is reached, it is 'permanently' a true case. E.g., showing a hash preimage to C x, H(x) == C. This can't change with the weather or anything else. Even things like timelocks -- although not obvious at first glance -- have this property. They express logic that says "given the chain is at this height, ...". This means that on any chain at such a height the txn is valid. CISV/CIOV semantics also fall in line with this description. It says, "given such an input U, ...". If that input is realizable one time, it is provably realizable across reorgs. However, that doesn't mean someone couldn't interrupt U from being created. But generally, with Reorg + Double spend, or Reorg > 100 blocks (potentially destroying CB reward), all bets are off as to the replay-ability of transactions.
I want to also point out that this "revocation" property -- to the extent it is something new that can't already be emulated with pre-signeds or RBF -- is entirely opt-in as far as CTV is concerned. You have to specify that an output can only be spent with another, most wallets shouldn't do that, and it can't "infect" other wallets to an extent more than spending from any recently confirmed output exposes you to more reorg risk.
In sum, we do not need to worry about this for CTV.
Lastly, I want to note that revocation is part of what CTV is designed to do (absent reorgs). It allows us to prune spending conditions by playing a transaction forward.
E.g., spending conditions {Alice & Bob, Preimage(H(X)) + Eve, CTV({Alice & Bob}, 1 day)}
Expresses that Eve has 1 day to reveal the preimage to H(X), otherwise Alice and Bob can take the coin back by removing Eve's HTLC path. What's cool about this revocation v.s. just {Alice & Bob, Preimage(H(X)) + Eve} is that Alice and Bob don't need to coordinate a multisig to revoke Eve.