Adjacent Is Not Inside
A scorekeeping tool for track cycling has one job: take heat results, apply the rules, produce standings. At the same meet, two feet away, there's a photo-finish camera and an electronic timing gate recording data about the same riders in the same races. It would be a small lift to let the scorer ingest that timing feed directly and auto-populate results instead of someone typing them in. A maintainer I know of refuses to build it.
On paper that looks like a missed feature. Timing and scoring are both "velodrome software." They touch the same event, the same riders, the same spreadsheet of final standings. Anyone pitching this as a roadmap item would call it a natural extension, not a departure.
But natural extension of what, exactly. The scorer's actual problem is rule application: given a result, what does the standings table say next. Timing's actual problem is sub-hundredth-of-a-second measurement under adversarial conditions, hardware triggers, sensor calibration, failure modes where the gate misses a wheel. Those two problems share a subject matter and share nothing else. Absorbing timing doesn't extend the scorer's competence, it adds a second, unrelated competence and makes the first tool answerable for failures it has no way to diagnose.
That's the part that gets missed when people evaluate a feature by asking "is this near what we do." Nearness is about the domain, about which nouns show up in both tools' documentation. The question that actually matters is whether the new thing needs the same kind of correctness, the same kind of state, the same contract with the person using it. A rules engine and a sensor pipeline fail differently, get debugged differently, and lie to their users in different ways when they're wrong. Stapling one onto the other doesn't make a more capable tool. It makes a tool whose interface no longer tells you what it's accountable for.
This is also, not coincidentally, how you end up unable to explain what a piece of software does in one sentence. The moment the answer needs a paragraph of carve-outs, the tool has already stopped being legible, to its users and usually to its own maintainers. A notes app that stays a notes app for a decade, through redesign cycles that killed half its competitors, stays legible precisely because "writes and finds notes" never grew footnotes about project tracking, databases, or team wikis. Every adjacent feature it declined to absorb is a sentence it got to keep.
Package managers that resist becoming build systems are the same story from the other direction, and build systems that resist becoming package managers are the mirror of it. Both problems live in the same toolchain, touch the same files, get solved by people who are often the same person in the same sitting. Fusing them has been tried more than once, and the result is always a tool nobody can describe without first explaining which half of it is currently running. The domains are adjacent. The problems, and the kind of wrongness each one produces when it fails, are not.
None of this is an argument against integration. Plenty of tools correctly hand off to a neighbor: the scorer can still read a results file a timing system exports, the editor can still shell out to the build system, the package manager can still call a compiler. Handoff keeps the seam visible. Absorption erases it, and the erasure is exactly what makes the tool stop being able to say, honestly, what it will and won't get wrong.
What's actually being protected when a maintainer says no to the obviously-nearby feature isn't scope for its own sake. It's the reader's ability to look at the tool and know, without a changelog's worth of exceptions, what kind of mistake it's capable of making. That's a narrower asset than "more capable software," and it's the one that keeps paying out ten years on, long after the feature request would have been forgotten either way.