>A refactoring that removes features is not a refactoring; it's a massacre.

Features that aren't used (or used in very rare cases) can, and in many cases should, be ruthlessly cut out in a refactoring.

By definition we care for the features that we care about. If noone (as in: very small value of "some people") cares about Amiga OS support, it should be removed to have a cleaner codebase.

Else in 2050 they'll be wondering what this Oric Atmos is, and why it needs 400 IFDEFS in vim code.

>And yes, removing features and support for some OSes is not a prerequisite for reaching neovim's goals. It will make it easier for them, that's for sure, but that is absolutely not a given, at all.

More mevelopers should get familiar with the notion of "opportunity cost".

Removing features that aren't used should often be done, but I'm hesitant to call it "refactoring". Most definitions say that a refactor doesn't change external behavior. Removing features has additional ramifications - good and bad - and probably deserves to be called out more explicitly.

Refactoring in its pure form yes, but people use refactoring to mean any large scale restructuring of a program not just following refactoring patterns that produce the same result as before.

In practice large scale refactoring and change in behavior (dropping some features, fixing some stuff) are pretty much tied together.

I don't object to using "refactoring and ..." for such. I've weak objection, in terms of clarity and what we should be clear about, to using "refactoring" alone for it. I agree that it's not terribly uncommon.

In practice, is it a feature to be available on a given legacy platform? For most users, no relevant feature is lost when legacy support is removed.