Anarki, at least, supports multi-character ssyntaxes, as I committed a .. ssyntax for range. The pos thing is still a good idea.
As you saw, bad ssyntax crashes because empty parts come out as #<eof>, as you saw; why that happens, I can't tell you. But I can tell you why you can't write things like a!(b c) or pr."test". The reason is that ssyntax (symbol syntax) isn't directly part of the read procedure. Structures like (tab!frob xs.ix) are read in as-is; after this, every symbol is traversed and possibly expanded, producing something like ((tab 'frob) (xs ix)). Thus, a!(b c) is read in as the two objects a! and (b c), and a! is then expanded to (a '#<eof>); similarly, pr."test" is read in as pr. "test", and then becomes (pr #<eof>) "test". Granted, those #<eof>s shouldn't be there---probably a syntax error should be produced instead---but that's what's going on.
So, maybe an arc implementation of the reader is in order? Then we could have arc level implementation of reader macros too, instead of just ssyntaxes and symbol macros.
So far, we have lib/arc-read.pack and lib/parser.arc, both in anarki, as well as lib/parsecomb.arc. Not only do you have your reader, but you have a choice of them too!
arc-read seems to be designed for easy extensibility although I haven't tried it at all. (If I had looked carefully before embarking upon parser.arc, I might have saved myself a lot of trouble).
parser.arc doesn't support the full range of scheme numbers, nor does it support |foo| symbol syntax yet, apart from ||. I'm working on a new version that will hopefully be faster - welder depends on the tokeniser for syntax highlighting.
parsecomb.arc, if I understand correctly, isn't an arc parser but a library for building parsers.
In any case, having an implementation of 'read in arc makes a lot of sense, and it's in the todo at the top of arc.arc
