When you consider this, it might suggest there's no SIGIL! datatype... they're just sigilized states of space (note that _ is now the space character literal, not a unique unit type)
>> lift _
== ^
>> pin _
== @
>> tie _
== $
That wouldn't change anything really about the functions asking questions like SIGIL OF. Same difference:
assert ['$ = sigil of first [$abc]]
It does mean we don't need to spend one of 63 fundamental datatypes on SIGIL!, which isn't totally useless.
It also means that we don't have to worry about explaining the difference between [$ @ ^] and [$_ @_ ^_] This seems like a pretty big win: the value of being able to decorate spaces in this way seems like it would be far outweighed by the cognitive load of having these forms be different.
Also, [$$ $@ $^ @$ @@ @^ ^$ ^@ ^^] would not exist.
As obviously good as forbidding those may seem...I strangely proposed using things like this back when COMPOSE didn't use the current environment, so I was thinking about bindable SIGIL!s:
>> $$
== $ ; bound
>> bar: 1020
>> compose2-old $$ [foo $bar baz]
== [foo 1020 baz]
Now this is less of a concern, since COMPOSE2 will use the current environment, so it can work with a Sigil that is not bound:
>> bar: 1020
>> compose2 '$ [foo $bar baz]
== [foo 1020 baz]
Actually, the whole priority of being able to pass the environment by means of the pattern is pretty much gone. It could just be an additional parameter to COMPOSE for the few cases that use it, and that would actually be simpler than the rigamarole and confusion of trying to put the context onto the pattern itself... which was an artifact of when COMPOSE syntactically needed to capture the environment to work.