I just point out that at least one assembler exists that succesfully solves the described problem so that can be taken into account in the question of how to move forward.
Well the multitude of bin/hex literal prefix/suffix options isn’t a problem per se, it’s mostly just an annoyance from a “clean language” perspective. It irks me 
.
About using $ to start symbols or omitting the 0-prefix for literals with H suffix, I disallow that to prevent the programmer from shooting himself in the foot. If you would e.g. define a symbol $face or Bah, on use it could be interpreted either as an integer literal, or shadow an integer literal, both undesirable. The third and only sane option would be to throw an error on definition of such a symbol (hm, sounds familiar). To the user the condition to trigger that error would be quite confusing (“Because your symbol matched the \$[0-9a-fA-F]+ production”). The grammar for labels would turn quite ugly.
Better to just disallow the entire class of $-prefix symbols. It’s not like it is generally supported by other assemblers or in general use, so I don’t need to do it for compatibility’s sake. The underlying (bad) thought was that I could maybe use it as an extension point for some built-in functions without conflicting with user symbols (e.g. “$size nop”). But it’s probably better to have a “glass” namespace and some kind of import statement anyway.
Basically, “that it can be done” doesn’t mean that “it should be done” :).
