This concept of separation is always interesting to me.

In the 1990s, when MVC was first conceptualized, a GUI was (a) native (b) playing the dual role of both View and Controller. It is quite hard (not impossible, but hard) to separate the app's UI from "the rest of the logic".

Consider trivial interactions (i.e. the Controller side of the UI element) like drags. What does a drag do? How do you conceptualize limits on the motion? How do you convey semantics between the Model and the Controller? How do you handle the differences between clicks (essentially drags with no movement) and actual drags? How does the Controller handle both axes? Gestures? etc.

Remember: the UI is the thing that receives input events from <somewhere, and in its capacity as the Controller, alters the Model state, which in turn causes changes in the appearance of the UI (as the View). This then creates additional issues if changes to the Model state are expensive (i.e. the Model contains/controls heavyweight resources), and thus Controller interaction must first work on a "pseudo-model" which is also represented by the View aspect of the UI, until the interaction is complete, at which time, the Controller propagates the actual change(s) into the "real" Model.

Yes, quite a bit of this has been revised/extended/expanded (e.g. Microsoft's View-Model concept), but the basic issues remain, and make the kind of separation you're thinking about hard to do in practice for all but basic data presentation applications.