> There are at least three or four separate covenants designs that have
> been posted to this list, and I don't see why we're even remotely
> talking about a specific one as something to move forward with at
> this point.

To my knowledge none of these other proposals (drafts, really) have
actual implementations, let alone the many sample usages that exist for
CTV. Given that the "covenants" discussion has been ongoing for years
now, I think the lack of other serious proposals is indicative of the
difficulty inherent in coming up with a preferable alternative to CTV.

Each covenant proposal aside from CTV has seemed either abstruse and
handwavy to me (TLUV, OP_EVICT) or general to the point of
being hard to analyze for safety (CAT) or encourages
witness verbosity that seems wasteful (OP_TX[HASH]).

CTV is about as simple a covenant system as can be devised - its limits
relative to more "general" covenant designs notwithstanding.
The level of review around CTV's design is well beyond the other
sketches for possible designs that this list has seen.

> We could just as well be talking about
> TLUV/CAT+CHECKSIGFROMSTACK/etc, and nearly anyone who is going to use
> CTV can probably just as easily use those instead - ie this has
> nothing to do with "will people use it".

This vault design (https://github.com/jamesob/simple-ctv-vault)
is a good benchmark for evaluating covenant proposals because it's (i)
simple and (ii) has high utility for many users of Bitcoin. I would
love to see it implemented in one or all of these alternatives, but I
am almost certain no one will do it in the next few months because the
implementations, tooling, and in some cases even complete
specifications do not exist.

Why that is after years of discussion and the utility of
covenants being widely appreciated is indicative to me.