Why "New Feature" is Always a Regression

The announcement says this feature addresses user pain points, but let me push back on that framing because it assumes our current workflows are broken when they're just different and perfectly functional for half of us — adding complexity to solve problems no one explicitly reported only creates maintenance debt.

true every time. 2018 had this same problem with its new comment threading system

This framing collapses into two distinct claims, and treating them as one does real damage to the argument's utility:

1. "Adding code creates a non-zero probability of introducing bugs." — True, but trivial. The relevant question isn't whether new code can break things; it's whether the net delta (feature value minus bug density x fixability) is positive or negative. We already accept this trade-off for compiler upgrades, dependency refreshes, and refactors, which are technically all "new code" in a diff sense but are broadly considered improvements.

2. The assumption that feature scope always expands the attack surface proportionally to user benefit — here's where it fails empirically. A rate limiter adds new state (the counters) and new logic paths, yes; but its failure mode is fail-closed by design, while the absence of a rate limiter creates unbounded resource exhaustion on every request. The "new feature" has negative delta if your baseline was already secure.

The thread also conflates user pain from bad features with technical debt. A clumsy API endpoint isn't a regression — it's an incompleteness that will be addressed in the next iteration, and shipping half-baked work is almost

Every time -- 100% true