Many commands break on unquoted special characters, quoting support inconsistent

What's wrong:

Many command arguments now only allow the same characters as unquoted NBT strings (a-zA-Z0-9._+-). For example,

/scoreboard objectives add custom:name dummy

is now an error.

Some commands allow you to put double quotes around the argument to fix this. For example,

/clear "A\"A"

attempts to clear all items from the player A"A.
Other commands do not; that scoreboard command, for example, is unfixable.
Still others have no issue with special characters, treating them just like any other character.

This behavior is very inconsistent:

/ban "A\"A"

bans the player "A\"A", but

/ban-ip "A\"A"

throws a parsing error.

I have identified three main ways that commands handle special characters:

• Broken: If the argument contains any characters that would not be allowed in an unquoted NBT string (allowed: a-zA-Z0-9._+-) parsing fails, usually with an error about trailing data before the invalid character.

• Quotable: If the argument starts with ", it is parsed as a quoted string. Otherwise, it behaves like a Broken argument.

• Ignored: All characters are allowed (with the possible exception of spaces ending the argument), and none are parsed specially.

These are used with no consistent pattern; player names, for example, are treated in all three ways by different commands.

What should happen:

Arguments that actually want to restrict their valid characters should display a clearer error message than "found trailing data". Additionally, the ability or lack of ability to quote arguments should be consistent between commands. I personally think that player names, objective names, team names, and tag names should always be quotable, mainly for the ability to use spaces in them.