Looks like I'm the long dissenting voice here? As the originator of the name CHECKSEQUENCEVERIFY, perhaps I can explain why the name was appropriately chosen and why the proposed alternatives don't stand up.

First, the names are purposefully chosen to illustrate what they do:

What does CHECKLOCKTIMEVERIFY do? It verifies the range of tx.nLockTime.
What does CHECKSEQUENCEVERIFY do? It verifies the range of txin.nSequence.

Second, the semantics are not limited to relative lock-time / maturity only. They both leave open ranges with possible, but currently undefined future consensus-enforced behavior. We don't know what sort of future behavior these values might trigger, but the associated opcodes are generic enough to handle them:

CHECKLOCKTIMEVERIFY will pass an nSequence between 1985 and 2009, even though such constraints have no meaning in Bitcoin.
CHECKSEQUENCEVERIFY is explicitly written to permit a 5-byte push operand, while checking only 17 of the available 39 bits of both the operand and the nSequence. Indeed the most recent semantic change of CSV was justified in part because it relaxes all constraints over the values of these bits freeing them for other purposes in transaction validation and/or future extensions of the opcode semantics.

Third, single-byte opcode space is limited. There are less than 10 such opcodes left. Maybe space won't be so precious in a post-segwitness world, but I don't want to presume that just yet.


As for the alternatives, they capture only the initial use case of nSequence. My objection would relax if nSequence were renamed, but I think that would be too disruptive and unnecessary. In any case, the imagined use cases for CHECKSEQUENCEVERIFY has to do with sequencing execution pathways of script, so it's not a stretch in meaning. Previously CHECKMATURITYVERIFY was a hypothicated opcode that directly checked the minimum age of inputs of a transaction. The indirect naming of CHECKSEQUENCEVERIFY on the other hand is due to its indirect behavior. RELATIVELOCKTIMEVERIFY was also a hypothicated opcode that would check a ficticious nRelativeLockTime field, which does not exist. Again my objection would go away if we renamed nSequence, but I actually think the nSequence name is better...