We had talked about swapping the default for 3.0 but punted.

When working on ArgAction during 3.2, I modeled it after Python's argparse which only supports overriding, making args_overrides_self the only behavior for the new actions.

When switching cargo to the new actions, some tests specifically checking for self-conflicts failed. This reminded me that in cargo 1.64.0, --target switched from a multiple_occurrences(false) to multiple_occurrences(true). This was a switch from an error case to a working case. If args_overrides_self had been on, it would have been a switch from a working case to a working case, being a change in working behavior.

We decided in 4.0.0 to defer a decision on the behavior and bring back args_overrides_self, making the new actions behave like the old ones,

So to summarize args_overrides_self(true)

• Allows easy overriding of previous arguments, especially if args/aliases are involved
  • e.g. alias ls='ls -xyz' would be safe to repeat some of those flagd
• Has compatibility hazards

So should we switch to it being on by default, only on, or maintain status quo?

Notes

• Overriding of self is the exclusive behavior for Python's argparse
• A user on Zulip thought args_overrides_self(true) was set
• A user reported the conflict error as a bug
• Most tools Josh has used seem to ignore duplicate flags, at least (e.g. rm -fffff file).
• And at least some tools silently override option values as well; for instance, touch -d 'Jan 1 1970' -d 'Dec 31 2400' file will use the latter timestamp.