NIL

Yup, I understand that. I guess the question is whether incorrect highlighting but able to execute is better than completely not working?

The client is parsing the whole command tree. So non-standard args will work for value arguments. But for literal arguments, like sub commands, it will fail to parse the command node and likely display red for every argument behind that, too.

Re-thinking about it, nuking `StringReader.readUnquoted()` may not be the best approach since it's also used to parse SNBT strings which doesn't support unquoted non-ASCII characters

From what I understand, it is possible to alter the behavior of ` StringReader.readUnquoted()` while maintaining the interface, similar to the `CommandNode,canUse(...)`.

// CraftBukkit start
    public synchronized boolean canUse(final S source) {
        if (source instanceof CommandListenerWrapper) {
            try
{                 ((CommandListenerWrapper) source).currentCommand = this;                 return requirement.test(source);             }
finally
{                 ((CommandListenerWrapper) source).currentCommand = null;             }
        }
        // CraftBukkit end
        return requirement.test(source);
    }

How so will the client fail though? I believe that the client will only crash if we return a type that's unsupported. Highlighting might not work as intended but I believe that it's still a major improvement over completely not working.

Even if Spigot patches that class the client is also using Brigadier and will likely fail.