To redo the singleton pattern in bitcoin's context, I think you'd have
to pass in both the full tx you're spending (to be able to get the
txid of its parent) and the full tx of its parent (to be able to get
the scriptPubKey that your utxo spent) which seems klunky but at least
possible (you'd be able to drop the witness data at least; without that
every tx would be including the entire history of the singleton).
Yes that's the idea. Since the parent transaction is in the blockchain it could be pulled in automatically without having to charge vbytes for it.
If softfork is just doing a best effort for whatever opcodes it knows
about, and otherwise succeeding, then it has to succeed, and your
script/output has become anyone-can-spend.
That can be alleviated by when things call untrusted code they can wrap it in a guard which can be the soft fork opcode itself.
On the other hand, if you could tell the softfork op that you only wanted
ops up-to-and-including the 118 softfork, then it could reject fakeopcode
and fail the script, which I think gives the desirable behaviour.
A simple approach to versioning like that may be more expedient. Soft forking in CLVM isn't implemented yet.