Subcommand path from a top/root context

I have a blocked issue https://github.com/platformio/platformio/issues/349 that depends on ctx.args option that was broken/removed? in Click 6 ( https://github.com/pallets/click/issues/473 ).

@mitsuhiko proposed to use Click 5 and what I've been doing last year. I don't see any progress on #473 and thought that maybe is something wrong with implementation?

Really, I need ctx.args leftover arguments on TOP level to determine different options from subcomamnds. For example, if deep subcommand supports --json option and developer uses it, I should be "silent" and don't print any info to stdout (planned updates, maintaince operations etc) because it will break final JSON. That is only the one use case.

The questions:

1. Do you know other approach how to receive a subcommand path from TOP/ROOT context?
2. How to receive a final context of subcommand having TOP context?

Using sys.argv without parsing will not help me. I have mix of deep commands/sub-commands. for example, pio command1 arg_cmd_1 --option_cmd_1 subcommand arg_cmd_subcommand. How to receive in this case path like [command1, subcommand]?

I see a few other options that requires some refactoring to existing @PlatformIO code and allow to switch to Click 6 and above:

1. Manually parse sys.argv - isn't good approach
2. Define custom Click-based Command class for @click.command(cls=MyCommand) where I'll know which command was called.

I use the same approach with MultiCommand as is in this example https://github.com/pallets/click/blob/master/examples/complex/complex/cli.py

What do I mean, is possible to know about deep subcommand in this position https://github.com/pallets/click/blob/master/examples/complex/complex/cli.py#L63 ?

For exampe, complex init --path /dev/null

Thanks!

Start with the complex MultiCommand example linked in the issue, especially the position around line 63, and review how ctx.args and nested command contexts behave across Click 5 and Click 6. Compare the requested deep command path and final context behavior for commands such as complex init --path /dev/null; done means a supported approach is identified or the API limitation is clearly documented.