Hi Mark,
Overall, I like this idea in every way except for one: unless I am missing something, we may still need an
OP_RCLTV even with this being implemented.
In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time.
I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed.
Best,
Stephen