So @bradrn ... if you're still out there, somewhere... you may be glad to know several types are getting the axe.
We've already discussed the demotion of TYPE-XXX!, once it was decided that trailing slash did a pretty fine job of letting you do type constraints:
>> parse ['abc 'def 'ghi] [some lit-word?/]
== 'ghi
So it became WILD-XXX! with no uses (while it was thought about whether & should be a SIGIL! at all).
Then something fairly major happened, in which things like ^foo.^bar became important... and important to consider as a TUPLE! consisting of META-WORD! elements:
Should sequences permit non-head SIGILs? - #2 by hostilefork
In one fell swoop, that killed off: (VAR-TUPLE!, VAR-CHAIN!, VAR-PATH!, META-TUPLE!, META-CHAIN!, META-PATH!, THE-TUPLE!, THE-CHAIN!, THE-PATH!) as fundamental types.
But as I note about the optimization profile, even if decorations live "under" the sequence type, we still want to sometimes have cases where the interpretation is as if they were on the whole type.
>> $foo.$bar
== foo.$bar
In order for that to be done efficiently, the best implementation is to have the guts under the hood of the Cell act as if there are these distinct "type bytes" (because that's the best place to store the variation). And right now, the most reasonable way to think of this is that the HEART_BYTE() is modulo 64 to get the secret sigil variation... permitting exactly 3 SIGILs: VAR, META, and THE.
So there's no room for the & Sigil in the most straightforward implementation. Paring things down to an even 3 variations.
Obviously I do not love the idea of etching in stone the number of sigils based on what fits in a byte. But ASCII is not going anywhere, and we're at a bit of a saturation point for the medium.
So maybe this will give you some peace in terms of a rationale, especially since your least favorite Sigil is gone. 