I'm not sure about changing standard digits; maybe there is utility in that — but I do believe that, if the standard digits aren't changed (i.e., if none of them is specified in the mask), they should be allowed as alternatives. Duplicates should obviously be an error.

As for a character whitelist, it's probably better to start by listing the things that shouldn't be allowed, just so nobody forgets:

• Anything not ASCII. This is a nightmare waiting to happen.
• Control characters. I hope I don't have to explain this one.
• Spaces and operators. I'm sure that someone out there is using + and - as digits, but the truth of the matter is that %++2 becomes ambiguous if you do that.
• Colons, semicolons and backslashes. :: would become ambiguous if it could be part of a number, ; would become confusing (particularly considering that some tools do parse code, which might interpret it as a comment), and \ is essentially always a problem.
• Quote marks. While those aren't ambiguous, it's a matter of time until they are mishandled.
• Parentheses, brackets and braces. The opening ones are unambiguous, but certainly nightmarish to process; the closing ones could lead to ambiguous syntax.

Agreed. Note, "operators" means + - * / % & | ^ < > = ! ~.

Omitting those, that leaves these ASCII characters:

• Letters A-Z a-z. Those are fine.
• Characters that are numeric literal prefixes: % & $ `. Disallow those.
• Underscore _. Probably disallow that, since it's the goes-anywhere "digit separator" in numeric literals. (On the other hand, it might be popular as a choice for 0.)
• Period .. Should be fine, since it's valid in local labels and fixed-point literals, and is a popular choice for 0.
• Characters allowed in identifiers: @ #. Should be fine.
• Comma ,. Disallow this, since it separates lists of numeric literals.
• Characters not used in the grammar: question mark ? and single quote '. Probably disallow these, since ' will plausibly gain use as a quote character (e.g. for character literals), and ? could become a ternary operator.

That leaves the whitelist as: A-Z a-z . @ #, maybe _, maybe 0-9, and maaaybe ? or '.

You should definitely at least also allow the digits themselves — so you can specify an alternative for just some of them. (Think opt b.1.) I'd honestly allow them all, but at the very least they should be able to represent themselves.

EDIT: note that this allows opt b01 as a natural way of disabling all aliases.

Yeah, that's why I said "Assigning a standard digit to a nonstandard placement should be an error."

Our current test cases:

test/asm/invalid-opt.asm:opt b123
test/asm/invalid-opt.asm:opt g12345
test/asm/opt-b.asm:OPT b.X
test/asm/opt-g.asm:OPT g.x0X
test/asm/trailing-commas.asm:   opt boO, g.xX#,
test/asm/underscore-in-numeric-literal.asm:     opt g_ABC, b_X

Most of those will become errors if they weren't already, and that's okay.

Note that invalid opt directives -- like opt b123 -- are currently non-fatal errors, so invalid chars like opt b$^ should be too.

Errors should always be the lowest category that they can be. That means that things that could be warnings should be warnings; things that can be non-fatal errors should be non-fatal. I couldn't tell you if it can be non-fatal, as I'm not implementing the feature; but if it can be, it should be.

EDIT: CLI options should fail right away, though. There's no reason to parse a file from a mistyped command line.

CLI options should fail right away, though. There's no reason to parse a file from a mistyped command line.

Yeah, things like rgbasm -b123 are instant-failure errors, so -b;% would be too.

Anything not ASCII. This is a nightmare waiting to happen.

But I need to do db %😻ඞ😻ඞ😻ඞ! (It's not ambiguous with any language syntax! :3 )