First mentioned here, though I've brought it up other places--usually when talking about paths, or while mentioning that not all words should be able to become antiwords. I thought you had approved and said "yes that seems sensible" somewhere.
I definitely want to reserve the meaning of unused antiforms for future purposes. That is a given. Antiforms are special states: the fact that they can be reified and inspected as normal values is just a convenience to simplify the "API" by which those special states can be handled and examined. So I don't want people creating antiforms today when they have no meaning, and then being bitten tomorrow when it's decided that particular antiform does something strange.
On the other hand, restricting quasiforms isn't as much a semantics thing as it is a mechanics thing. I mention the path issue--where we'd either have to prohibit quasiforms in things like paths/tuples/chains... or there'd have to be some kind of special notation.
>> to path! [~ a ~]
== ~~/a/~~ ; ~~ is a SIGIL!, but sigils can't be in sequences, so...?
>> to path! [~ a ~]
== ~\~/a/~\~ ; ick
>> to path! [~ a]
== ~/a/ ; would you just know it's not a quasiform due to the half state?
I don't like the shaky-feeling workarounds, and would rather just say there are no quasiform paths/tuples/chains. The direction I prefer is reified escaping, e.g. ~(~/a/~)~
There are some casualties here which seem useful--like ~10~. It is possible that there could be types that allow quasiforms before having antiforms. But until antiform integer has meaning I'm willing to wait a moment or two to make the call on things like quasiform integer. If antiform integers actually do wind up having an important meaning, that might inform how dialects use it...so best not to get too attached to random uses until it's known what their antiforms are for.
Anyway, the key was just getting the mechanism in place to have systemic checks.