I'll give a recent exemple, [this PR](https://github.com/nim-lang/Nim/pull/20298) broke libp2p (and other repos), we noticed it fast since we have daily CI running against unstable
It was supposed to _improve_ enum resolution, but evidently made it worst since it broke existing code. Now that it's merged, I doubt it's going to get changed, unless someone pushes a lot for it (I already tried on the PR without much effect) If libp2p (or other affected package) was part of the important_packages, it would have prevented this PR from being merged as-is, and at least start a discussion on "Does this PR make sense" Same thing happened with `nimPreviewDotLikeOps`, which actually made the "dot like ops" worst than what they were before instead of improving them, and took months to be reverted. Meanwhile [questionable](https://github.com/status-im/questionable) and any repo using it wasn't usable on Nim devel. The fact is, once something is in Nim's `devel` it's a bit painful to revert / fix. Maybe the original author isn't around anymore, or he just doesn't have time / motivation to continue working on it. So we better make sure something is good before merging it. Giving the PR author ability to see what his PR is breaking, and letting him check if this breakage make sense (ie, the package might be relying on sketchy behavior) is very positive IMO
