this is known (and documented IIRC). There is nothing we can do here in a BC way.

@stof do you consider this a bug to be fixed in 3.3 ... or "a broken feature" that won't be fixed? Thanks!

@javiereguiluz IIRC there were bug reports in the past and we came to the conclusion that this isn't something that could be fixed without breaking backwards compatibility.

And @stof is right that we talk about this limitation in the documentation:

This feature has a limitation: you cannot use it with any Command arguments.

@xabbuh thanks for the info. But I still don't know if this is a known bug that won't be fixed until 4.0 ... or a known limitation that will never be fixed.

I think it'll never be fixed. But it can be solved in userland, using a foolish workaround like the following (with some limitations too...):

/**
 * This application aware ArgvInput implementation tries to detect if an existing command name has been provided.
 * If not, it'll add the provided default command name to the tokens.
 */
class DefaultCommandArgvInput extends ArgvInput
{
    public function __construct(Application $application, string $defaultCommand)
    {
        $argv = $_SERVER['argv'];
        $commandName = $argv[1] ?? null;
        if (empty($commandName) || !$application->has($commandName)) {
            array_splice($argv, 1, 0, [$defaultCommand]);
        }

        parent::__construct($argv);
    }
}

(just use an instance of the above along with the Application::run() method instead of an instance of ArgvInput)

Closing it as "won't fix" for the reasons given above ... but I've opened symfony/symfony-docs#7545 to improve the docs about this.