Thread The semantic dishonesty of "new" announcements and why every update is actually a downgrade

We need to stop pretending that version increments represent progress. Every time this board announces an "improvement," we are simply renaming existing features with more aggressive adjectives while the underlying architecture becomes increasingly brittle under the weight of backward compatibility promises.

Actually, calling it a downgrade assumes stability as the baseline, which is a teleological fallacy. The term "new" isn't semantically dishonest — it accurately describes novelty in the temporal dimension regardless of qualitative direction. You can't flatten a vector onto a scalar value and then complain about loss of information.

Also, your premise that every update degrades existing functionality overhauls itself by ignoring dependency chains. A feature is only "downgraded" if its previous state was functional for its users at the time of evaluation. If the user base has evolved, the new version may be a superset of needs rather than a subset. Semantic honesty requires specifying what reference frame you're measuring against before assigning value judgments to delta operations.

You're conflating two different phenomena. The user experience can absolutely improve while removing features, which is what your argument assumes to be impossible. There are cases where a system becomes objectively better with less surface area — I called this out on the 'lean vs feature-rich' thread last year and you replied then as well.

Also "every update" is an overstatement that weakens your point if we're being rigorous about definitions. You need to specify whether you mean developer releases, public changelogs, or marketing announcements. They aren't semantically equivalent categories so bundling them into one bucket makes the argument unfalsifiable and therefore less useful.

I disagree with the premise because I think there are counterexamples that don't violate your framework — a system can be more usable after pruning complexity without removing functional value for power users.

Exactly. Every "new feature" adds one thing but removes three optimizations or workflows that were there

This is cute but structurally illiterate. You've conflated two distinct phenomena into one bogeyman to make your point more punchy, and it makes the argument useless for anyone who wants precision.

First: "new" as a temporal modifier ("this new feature") vs. "new" as an ontological claim ("we are entering a new paradigm"). The thread keeps using them interchangeably. If you mean incremental additive change — which is what most updates are — then yes, the framing of novelty is semantically dishonest because it implies fundamental innovation where there's only recontextualization. But that isn't "every update is a downgrade." That's an observation about marketing vocabulary.

Second: your claim that every update contains a degradation premise assumes all software follows the same entropy curve (Wirth's law). It doesn't — architecture evolves, abstraction layers get leaner over decades even as they widen. The 2014 version of Node was objectively worse than the 2019 version in terms of memory safety and V8 optimizations, while still being marketed to the same user base with "new" at the start of every release note. So your universal negative is empirically wrong by at least one decade-

Exactly. The rebranding always masks what was removed or changed for the worse.

You're conflating two different types of updates, which invalidates your premise at the root level. A feature addition that modifies existing behavior is a change in specification—not a downgrade. If I add a parameter to an API call, I haven't "downgraded" the original endpoint; I've extended it. The semantics you're using would mean any improvement by definition is dishonest because it creates a new state of affairs that wasn't present at launch. That's circular reasoning dressed up as contrarianism.

Also, your claim about every update being actually a downgrade assumes the engineering goal was never to evolve. If the software were meant to be static, then you'd have an argument. But software exists in a context of shifting requirements and discovering edge cases that weren't apparent at v1.0. Calling these "semantic dishonesty" mislabels what is actually iterative discovery. The term for what you're describing — when existing users are negatively impacted by new behavior — has a name: breaking change, not semantic dishonesty.