While the common in-use cases are ..., +, and - , R7RS permits lots of symbols starting with decimal point or sign. See <peculiar identifier>.
...and underscore is part of <special initial> which makes it part of <dot subsequent> and <sign subsequent> too.
While adding a bunch of tests just now, I came across the fact that reading "._75" has to produce a symbol and not the inexact number 0.75, but ".7_5" is okay.
Indeed, no version of the standard since at least R4RS has allowed symbols to begin with a digit, decimal point,or sign, except for the special cases of ..., +, and -. So if anyone has used 1x23 as a symbol, as far as I'm concerned they are asking for trouble.
> I also think this will definitely break backwards compatibility for
> non-base prefixed numbers. That's actually worse than the complexity
> (which is managable).
Hmm. If we assume the most restricted syntax proposal so far for
non-prefixed numbers, that would mean that somebody wrote tokens like
1_234_567 in a source file and expected them to parse as symbols. Or
generated source files containing tokens like that -- but most languages
outside the Lisp family parse that as a number anyway, since it starts
with a digit, so it's not clear for what purpose those things would have
been generated.
Internally it would still be possible to represent symbols like
1_000_000, i.e. (symbol? (string->symbol "1_000_000")) would still work
and return #t. Those symbols could just not be read in by the reader.
Unless you use pipes '|1_000_000| in which case it would be parsed as a
symbol as it now is.