From discussion in #11674, particularly in #11674 (comment).

There's also related discussion in #13068 (comment).

We have the breaking change contract, which basically promises that there will never be significant breaking changes in PowerShell, for some value of "significant".

While a reluctance to make breaking changes is a strength in a platform, and there are definitely some breaking changes that are too divergent to implement, I think no software can stay evergreen without making breaking changes. Indeed PowerShell has already made a number of them, but in an ad-hoc way that doesn't properly catalogue or otherwise handle them. In particular, PowerShell has some "bad old" legacy edge- and corner-cases that would be nice to change, but to do so we need some pathway to making those changes.

I think we need to confront PowerShell's need to make breaking changes in PowerShell and discuss what can be implemented both at process and technical levels to ease such changes.

Basically we need a way to implement breaking changes softly, so that:

• The changes are out there, but old scripts can still run on them
• Users have a way to discover breaking changes, where they will be affected, and be given time to migrate over

Some ideas off the top of my head:

• The experimental feature system could be expanded to also capture and opt in/out of breaking changes
• We already have the breaking change PR tag, but should expand this to make it easier to query
• We should establish some sane way of funneling breaking changes into PSScriptAnalyzer. For Parser changes, this hits the hurdle of needing a particular version of the parser (one of the reasons I've argued strongly against syntax breaking changes). To address this, we might need to spin the parser out into its own NuGet package
• We probably would need a review process to decide which breaking changes can be kept and which must be reverted. This could be very hard to establish though, since the likelihood of a breaking change being picked up by a script depending on it not to break is low given our usage statistics
• We would also need a way to ensure that breaking changes are only picked up as default behaviour in the right semantic versions, or at least in the versions desired by the PowerShell maintainers

Crucially, anything we implement must scale so it can lean heavily on automation. Processes requiring heavy time investments are unlikely to work no matter how aspirational the language.