If two options share an alias, the second doesn't get parsed correctly #2726
Description
What Happens
For example, I have a command transform which has an option --response, and another command transform-all which also has an option --response. I cannot assign the same option to both because I need the type to be different (in my case, they are enums with different values, so the --response option for the transform command should accept values { No, Yes, Manual }, and the --response option for the transform-all command should accept values { Cancel, No, Yes, Manual }).
What happens is that the transform command works perfectly as intended, whereas the transform-all command uses the option from the transform command and thus does not accept a Cancel value (the library gives a runtime error saying it cannot parse that value). Furthermore, even if I pass transform-all --response No, the library does not give a runtime error but instead quietly assigns the default value for the option (Manual in my case), which then produces unexpected behaviour on my end.
What Should Happen
The library should be able to parse two different options even if they have the same aliases, as long as those options are not assigned to the same command.
I believe this is consistent with the current design philosophy of the library, because if we try to pass an option that exists only on one command to another command, the library gives an error and does not acknowledge this option's existence at all. For example, again in my case for the transform-all command I have a --quiet option, but for the transform command I do not have that option. If I try to pass transform --quiet it gives an error saying it does not recognise the option --quiet. Notably, it does not say "--quiet option is not supported for the transform command": it does not even acknowledge the --quiet option's existence at all. It behaves the same as if I had passed --gjfdkljgfdkljgldkf. This behaviour is correct, and it demonstrates that the library views options as attached to their commands and not to the whole app itself.
Therefore two options that happen to have the same aliases that do not share a command in common should not interact with each other at all and both should be parsed correctly.
At the very least, even if it is decided that the current behaviour is intended, the library should not quietly incorrectly parse one of the options, and should instead explicitly throw an exception to let the developer know that this feature is not supported, instead of having them think it's supported and then causing bugs.
Other Info
I am using the System.CommandLine 2.0.0 NuGet package in .NET 10.