^{Note that the term technical debt is used loosely here to mean "accumulated broken behavior that can't be fixed without breaking backward-compatibility"; strictly speaking the term has a different, specific meaning.}

Update: @rjmholt has started a discussion about how to implement and manage breaking changes: #13129.

Note: This issue, which arose out of #5551 (comment), is just to get the discussion started to see if there's a fundamental willingness to entertain such changes. Eventually, RFC(s) are needed.

PowerShell's steadfast commitment to backward compatibility has served the community very well over the years.

On the flip side, the inevitable by-product was the accumulation of technical debt that requires memorizing exceptions and is a barrier to newcomers.

Certain fundamental problems that exist today can only be solved at the expense of backward compatibility, and there are two - not mutually exclusive - ways to handle that:

• Implementation of a "PowerShell vZeroTechnicalDebt" edition that sheds all technical debt, but forfeits backward compatibility (possibly with future versions using semantic versioning to indicate compatibility)

• Integration of backward-compatibility-breaking features / fixes into the existing code base, available strictly on an opt-in basis only.

Which approaches, if any, are we willing to consider?
Once we have clarity on that, we can flesh out the processes.

Here are some of the existing fundamental problems that can only be solved at the expense of backward compatibility; I'm sure others will think of more:

• The complexity and inconsistency of current error handling and problematic [lack of] integration with "native" (external) programs - Inconsistent handling of native command stderr  #3996

• Inconsistent, hard-to-predict preference-variable / common-parameter inheritance - Need straightforward way to honor the caller's preference-variable values / inherited common parameters in functions defined in script modules #4568

• Performance issues due to [object[]] being the fundamental collection type - PowerShell should support creating an List similar to how it supports arrays #5643 (comment)

  • While PowerShell understandably will never match the speed of Unix utilities, it is all the more important to make interop with them predictable and as painless as possible - see remaining issues re quoting and parsing.

• Problematic dynamic features that should work lexically: Foreach loop using | % {} syntax doesn't support continue #3879 (comment) re break and continue, https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0003-Lexical-Strict-Mode.md re Set-StrictMode (though the latter may be fixed without breaking compatibility)

• [psobject]-related problems (though perhaps they can be fixed without breaking compatibility): Should all [psobject] cmdlet parameters be changed to [object]? #5551, Objects are situationally invisibly [psobject]-wrapped, sometimes causing unexpected behavior. #5579, -as operator does not recognize System.Management.Automation.PSCustomObject instances as such #4343, Preference variable $OutputEncoding in child scopes misbehaves with encodings created with New-Object / commands rather than expressions #5763

• The unfortunate -LiteralPath / -Path split - brief rationale at Output-to-file cmdlets should not support wildcards with -Path #6714 (comment) and escaping woes at Output-to-file cmdlets should not support wildcards with -Path #6714 (comment) (not sure there's a good solution)

• Broken quoting for external programs - Invoking external command lines (utilities) is broken with respect to quoting on Unix #3734, Start-Process doesn't pass arguments with embedded whitespace and double quotes correctly #5576 (and others) and the related languishing RFC

• -Command and -File CLI argument parsing - Command line arguments with a dollar sign #4024 (comment), CLI: pwsh -Command - and pwsh -File - unexpectedly exhibit pseudo-interactive behavior, lack support for argument passing #3223 - and general misalignment with the CLI of POSIX-like shells - Align PowerShell's CLI / startup behavior with POSIX-like shells such as Bash - command-line arguments #3743 - including user profiles getting loaded by default even in non-interactive (script) invocations - #!/usr/local/bin/powershell bang should not load profile #992

• Inconsistent and surprising parsing of compound command-line arguments - Parsing of compound command-line tokens into arguments is surprising #6467 - and non-parameter tokens that look like parameters - Parameter parsing/passing: an unquoted argument that starts with a "-" (hyphen) is broken in two at the first "." (period) #6291, Parameter parsing/passing: an unquoted argument that looks like a named parameter/value pair separated with ":" (colon) is broken in two in positional binding #6292, and Parameter parsing/passing: unquoted tokens that look like named arguments with colon as the separator are broken in two when passed indirectly via $Args / @Args #6360

• Broken handling of ValueFromRemainingArguments parameters, as argued in Parameter binding problem with ValueFromRemainingArguments in PS functions #2035 (comment), with broken behavior shown in Write-Output -NoEnumerate outputs PSObject[] rather than Object[] and generally doesn't respect the input collection type #5955 and Write-Output -NoEnumerate wrap singular items into PSObject[] #5122 - going back to Fix Parameter Binder bug with Advanced Functions and ValueFromRemainingArguments #2038

Environment data

Written as of:

PowerShell Core v6.0.2