Unexpected argument parsing for scheduled Artisan commands

[mortenscheel]

Laravel Version

10.15.0

PHP Version

8.2.4

Database Driver & Version

Not relevant

Description

Take this simple Artisan commands, which has a named argument:

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Log;

class ExampleCommand extends Command
{
    protected $signature = 'app:example {name}';

    public function handle(): int
    {
        Log::debug('Artisan debug', ['name' => $this->argument('name')]);

        return self::SUCCESS;
    }
}

When called via the Artisan facade like this, it works fine:

Artisan::call('app:example', ['name' => 'John Doe']);

Output:

[2023-07-17 09:14:13] local.DEBUG: Artisan debug {"name":"John Doe"}

But when run through the scheduler like this:

$schedule->command(ExampleCommand::class, ['name' => 'John Doe']);

Then the argument name is included in the argument value:

[2023-07-17 09:16:54] local.DEBUG: Artisan debug {"name":"name=John Doe"}

The same is not true for options. They are parsed the same way in both cases. I realize that it's simple to fix by using a non-associative array in stead like this

$schedule->command(ExampleCommand::class, ['John Doe']);

But I hope you'll consider either mentioning this difference in the docs or make the argument parsing more consistent.

Steps To Reproduce

See example in the description

[driesvints]

You need to use non-associated arguments. I don't think we document it with arguments?

[mortenscheel]

You need to use non-associated arguments. I don't think we document it with arguments?

Still it's an inconsistency that you wouldn't expect in a framework that is otherwise very consistent. If there is a practical reason why they have to different, that's fine, but in this case it seems completely unnecessary.