[rootvector2]

handleProperties calls processValue on the Option registered in Options instead of on the copy that handleOption clones into the CommandLine, so a default applied in one parse() stays on the shared Options and every later parse() on it returns that stale value while an explicit -a two on the command line is pushed into the args list; found while checking why DefaultParser never clears option values the way the legacy Parser does for CLI-71.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute? Claude Code helped write the fix, the test, and this description.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.

[dajiaohuang]

One regression to account for: this removes the existing opt.isValuesEmpty() guard and always calls currentOption.processValue(value). Option.getValuesList() returns its mutable backing list, and Options.addOption(Option) stores the supplied instance, so a caller can register a one-argument option with an existing value (for example, add preset to getValuesList()) and then parse a property for that key. handleOption clones that full option; currentOption.processValue then throws IllegalArgumentException because the copy has already reached its argument limit. Before this change, the property value was skipped and the existing value was preserved. Could the empty-value condition be retained when applying the property to the clone, with a regression test for this case?

[rootvector2]

Good catch, the clone keeps the preset value so processValue hits the arg limit. Restored the isValuesEmpty() check on the copy (currentOption) and added DefaultParserTest.testPropertyDoesNotOverridePresetValue. Without the guard it fails with Cannot add value, list full., and with it the option keeps preset. The test lives in DefaultParserTest and not AbstractParserTestCase because the legacy Parser clears option values before each parse.