> Pretty sure making emacs render smoothly in 2016 was not an isolated change--even if the code change were only a single line.

This was a corner case. What I meant is the couple dozen packages I have in my Emacs that are well-interoperating but otherwise independent, and can be updated independently.

> Or, just think about your phone. If I put my head to the speaker, a sensor detects that, and the OS turns off the screen to save power. If I'm playing music to my Bluetooth speaker, and a call comes in, it pauses the song. When the call ends, the song automatically resumes.

These each affect a small fraction of code that's running on your phone. Neither of them is e.g. concerned with screen colors/color effects like night mode, or with phone orientation, or with notifications, or countless other things that run on your phone in near-complete independence.

Buttery smooth emacs is not a corner case. When working on API-level things (for those who don't know--emacs is practically an operating system), if we care about not breaking things, one must be highly cognizant of all the ways that API is consumed. Even if the final change ends up being very small code-wise, the head-space required to make it is immense. That is why we have (relatively) so few people who make operating systems and compilers that are worth a damn.

Most emacs plug-ins aren't operating at that level of interdependence. This one is working on a text buffer at t0, and that other one is working on a text buffer at t1. Of course, the whole thing can be vastly simplified if we can reduce interdependence, but that is not the way the world works. Typical end user doesn't want emacs. Typical end user wants MS Word.

Even if I accepted the replacement of my word "feature" with your word "program" (not that I do), one only needs to look at Docker's prevalence to see the point still holds. Interdependence is hard, and sometimes unavoidable.