Previously, running e.g. bin/cake i18n nonsense silently invoked I18nCommand and ignored the nonsense token, because:

• i18n is a registered command (the interactive I18nCommand).
• i18n defines no positional arguments, so ConsoleOptionParser::_parseArg() silently appends extras instead of rejecting them.

That hid genuine typos and made it look like CakePHP accepted any garbage after a known command name.

What this changes

In CommandRunner::run(), after the existing command-name resolution, when all of the following are true:

• the matched command exists in the collection,
• there is at least one more positional token,
• that token is not option-like (does not start with -),
• the matched command has sibling subcommands (i.e. there are other commands registered with <name> as a prefix),

then the next token is almost certainly meant to be a subcommand. If it doesn't match a registered subcommand, error out with a clear message listing the available subcommands.

$ bin/cake i18n nonsense
<error>Error: Unknown command `cake i18n nonsense`.
Available subcommands: `i18n extract`, `i18n init`.
Run `cake i18n --help` to see usage.</error>

What this does NOT change

• Commands without sibling subcommands (the common case) — unchanged.
• Commands that declare positional args via addArgument() — unchanged; the parser already validates them.
• Commands like RoutesGenerateCommand that intentionally accept arbitrary positional args (bin/cake routes generate controller:Articles action:view 2) — unchanged, because routes generate has no sibling subcommands.
• Option-like tokens (--help, -v, etc.) following the command name — unchanged.

Related

• Fix error message for too many arguments #19423 (merged on 5.x): off-by-one in the existing "too many arguments" message.
• Improve help command usage. #19424 (open on 5.x): cleans up the prefix-only case (bin/cake schema_cache nonsense) by routing to filtered help with only the prefix as argv. Complementary to this PR.

Alternative considered

Removing the silent-accept branch in ConsoleOptionParser::_parseArg() to make every parser strict by default. This was implemented and tested, but it breaks commands (including core's RoutesGenerateCommand) that intentionally accept arbitrary positional args without declaring them, and surfaces several test bugs around boolean options being passed values. That route would need a new opt-in API (e.g. a $parser->allowExtraArguments() flag) and a wider migration. Out of scope for this PR; happy to follow up if there's appetite.