This reply was offered by Pieter Wuille (@pwuille) on Twitter.
Conceptually it would not make sense, as a result of script circumstances are monotonic. What would and(pk(A),not(pk(B))) imply? “B doesn’t signal” is trivially glad; B would simply by no means trouble signing.
Equally, not(older(N)) wouldn’t imply youthful(N). There (deliberately) doesn’t exist a method in script to specific a younger-than situation (as a result of it will imply a tx that invalidates itself). “not(older(N))” would simply be “don’t show time is previous N”, additionally trivial.
For instance, Miniscript l:older(N) interprets to IF 0 ELSE <N> CHECKSEQUENCEVERIFY.
CSV and CLTV do not truly observe the time; they observe the nLocktime/nSequence subject within the transaction. There would not be any issues with having a capability in Script to make arbitrary (together with lower than, negation, …) statements about them.
Nonetheless, it will doubtless be pointless. The nSequence and nLocktime fields themselves do observe time, and may solely categorical larger-than constraints. Bitcoin transaction validity ought to be monotonic: as soon as legitimate, absent double-spend, they continue to be legitimate.
The choice could be a logistical nightmare. All mempool transactions would have to be reevaluated each block. Reasoning about validity of unconfirmed transactions could be a ache (e.g. what should you’re paid utilizing a tx spending the output of a soon-to-be expired tx?)