Summary of the new feature / enhancement

Parameter conflict validation errors (e.g., "Cannot specify both -X and -Y") currently use inconsistent ErrorCategory values across cmdlets:

Note: Select-String's error is a dependency requirement rather than a mutual exclusion, but it shares the same inconsistency issue.

Standardizing ErrorCategory and ErrorId naming for parameter validation errors would improve consistency and make error handling more predictable for users and scripts.

Key questions for discussion:

1. Can a cmdlet parameter be considered an "argument"? If yes, InvalidArgument would be semantically appropriate. If not, a new InvalidParameter category might be more accurate, though this would require PowerShell Committee approval as a public API change.
2. Should ErrorId naming also be standardized? Currently there are two patterns: CannotSpecify... and FormatCannotSpecify....

Related: #26472 (discussion origin)

Proposed technical implementation details (optional)

Options include:

• Option A: Standardize on InvalidArgument and FormatCannotSpecify... prefix (align with Format-* cmdlets)
• Option B: Standardize on InvalidData and CannotSpecify... prefix (align with Csv/Select-String cmdlets)
• Option C: Propose new InvalidParameter category with unified CannotSpecify... prefix (requires Committee approval, longer timeline)