Earlier quoted context omitted.
> visual and non-visual parts are separated globally, not on a view-by-view basis Yes, yes, and YES! This is something that confused me greatly over the last years: teams/companies I was in contact with were really struggling getting MVC to work (never mind MV*) and I wasn't...but I wasn't doing anything special, at least not that I could tell. I would implement my model, TDD-style, put minimal views on top, possible…
Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API? Please forgive the lack of background of this next question, but does this mean you do not support BFF pattern? Have you heard of Dubray's SAM (State-Actor-Model) approach? Curiou…
Yes, exactly that. Not my idea, of course. See for example Hexagonal Architecture. Or good old NeXT Enterprise Objects Framework, later extended by WebObjects.
> Have you heard of Dubray's SAM
No I hadn't, thanks for the tip!
He identifies one of the core problems with how MVC is incorrectly applied:
"The core issue here is [that in] traditional MVC, the action (controller) would call an update method on the model and upon success (or error) decide how to update the view. "
https://www.infoq.com/articles/no-more-mvc-frameworks/
However, he incorrectly claims that this is "traditional MVC". It is not. In fact, traditional MVC clearly forbids this, as it states that the View updates itself from the model. The View is active, you don't push data to the view.
Model -> View communication is a notification. That's it. (This is also how it is implemented in Smalltalk MVC, which is the prototypical and archetypical MVC implementation).