waxwing on Nostr: I think there are two different concepts of 'danger' that apply here. One is, that a ...

I think there are two different concepts of 'danger' that apply here. One is, that a "new" OP code may cause the potential for technical failures, things that could crash nodes for example by exhausting memory. Another is seen in cases like drivechains proposals, where some argue that, if the proposed change creates economic incentives to do things other than the purest model of 'miners just mine to get fees from onchain monetary transfers', then this is a danger that may be unacceptable.

I agree about the former danger, in that conservatism w.r.t. it is very necessary, but not with the latter: trying to mandate the semantics of onchain transactions is a false trail; if people want to do bitcoin transactions whose purpose is not purely the monetary transfer onchain, you are never going to be able to stop it. The problem with the argument "well there's no reason to *encourage* them, by adding new functionality!" is simply that there is, indeed, a very good reason: in order for bitcoin to be usable at large scale, it may be (and probably is) necessary to change its expressivity so that offchain transfers become significantly more powerful than today (e.g. Lightning cannot scale to the whole planet).

My intuition is that OP_CAT is more dangerous than OP_CTV w.r.t. the 1st danger, not that I really know.