Interrupt signal handling was called out in the CLI extension proposal as an area of active search; here we decide to go with the option of aborting the sub-command on interrupt to unblock this work. This will be re-evaluated after gathering more data.

This may be good enough. On nix-based platforms, I think we should consider tunnelling signals (e.g. sigint) and on context timeout, sending sigterm in this case instead of sigkill, but on Windows hard kill like this is acceptable. We will need to test I think.

The CLI extension proposal describes the question of "whether flags of parent commands can still be placed before the extension command" as an area of active research. For now we require them to be placed after the extension command to disambiguate. This will be re-evaluated after gathering more data.

I think you should find the most applicable built-in sub-command, remove all common flags on that subcommand, then do your extension resolution (and pass along all of those flags to the subcommand). And you should fail if there are unrecognized parent/common flags before the subcommand. For instance, I would expect:

• temporal --output json my-command --some-bool-arg to run temporal-something --output json --some-bool-arg
• temporal --no-json-shorthand-payloads my-command to run temporal-my-command --no-json-shorthand-payloads
• temporal --address 1.2.3.4:5678 workflow --tls diagram to run temporal-workflow-diagram --address 1.2.3.4:5678 --tls
• temporal workflow --some-bool-arg diagram to fail with "unrecognized flag --some-bool-arg"
• temporal --some-arg some-value workflow diagram to fail with "unrecognized flag --some-arg"

I have not investigated how to do this yet or how much of it is possible, but you cannot comfortably know which flags accept values and which are standalone to do some kind of arbitrary parsing. May have to put a ArbitraryArgs on every command. I can help with a PoC of this if needed.