> if all or almost all of your controllers match up to precisely one view, then you're burning design budget on a distinction that is buying you nothing.

Could you give an example? I've never understood how one could possibly reuse a Controller independently of a View. At a minimum any kind of mouse-based direct manipulation requires the Controller having access to the displayed geometry in order to implement hit testing. E.g. how is a Controller supposed to update the selection range in a text editor without screen-coordinate character extent information from the view, or a drawing editor Controller accessing scene graph geometry for object selection, control handle manipulation, etc.

> I've never understood how one could possibly reuse a Controller independently of a View.

And you're absolutely right!

The problem you're seeing is one of the misunderstandings/misinterpretations of MVC, that the controller is for all interactions/editing. It's not. It's perfectly fine for the View to handle this.

Honestly I think that was a stretch all along. It is conceivable that two views could present a similar enough interface that the same controller could drive them, e.g., an isometric and an orthographic view on to the same object might be able to be driven by the same controller, which, recall, is doing things like propagating changes between the two views, not just "driving" them directly, so if the view is controlling the coordinate mapping you might be able to use the same controller for both. In practice I suspect things end up 1-to-1 on the View and the Controller fairly often, although in an inheritance-based system there's probably some useful shared functionality in superclasses within a given system that could arguably fuzz whether or not it is "truly" 1-to-1.

In practice most "MVC" in the wild in things like web frameworks where it is just completely inappropriate is actually "M and everything else"; there's a clear Model, and then a whole bunch of code that uses models and changes models but that is not usefully modeled by a "View" and "Controller" distinction. MVC is completely missing a client-server concept as well, and it really shows. And while I will absolutely say that that design is not only not "true" MVC but isn't meaningfully "MVC" at all, what it actually is is not so bad. "Models" have great utility in many places, indeed is arguably one of the fundamental tools of programming, but "VC" is something that can be applied to them in certain circumstances but don't otherwise have any particular special relationship to "Models" such that where ever a model goes some Views and Controllers must be tagging along. Models are everywhere, MVC is a useful concept in certain domains where the requirements drive in that direction super, super hard (and web frameworks are not one of them).