The MVC pattern component interactions are described this way on Wikipedia:
The model is responsible for managing the data of the application. It
receives user input from the controller. The view means presentation
of the model in a particular format. The controller responds to the
user input and performs interactions on the data model objects. The
controller receives the input, optionally validates it and then passes
the input to the model.
I understand that the View should not be able to interact with the Model. But in most of the diagrams I find on the net, MVC is represented like this:
We can see that Model does interact with the View and is able to modify it, and it doesn't make sense.
Doesn't the Model update the Controller, that updates the View?
What am I missing?
The MVC architecture was created in the 1970s. Obviously there was no Internet at that time. In the original version, the Model directly updates the View through data binding, also known as publish/subscribe, also known as the Observer Pattern.
The Gang of Four Design Patterns book describes this MVC architecture in detail. A couple of quotes from that book are in another answer here.
The MVC architecture was very popular, and when the Internet came along, developers wanted to continue using it; but it didn't fit nicely into client/server applications. Thus was born "WebMVC", the version you most commonly see today. WebMVC is typically implemented as a layered architecture, which the original was not.
Confusion ensues when the two architectures are conflated. Often both are referred to simply as MVC. Even worse, related architectures such as MVP and MVVM can be called MVC.
Personally, I find the relationship between desktop MVC and web MVC somewhat like the relationship between Java and JavaScript. The latter piggybacked on the famous name of the former, to implement something significantly different.
related: Is it MVC when the view doesn't interact with the model?
No you can't access view with model directly, you must access controller first
as its MVC Pattern
Diagrams - worth a thousand words! The precise words and context used in the diagram maybe doesn't tell a story of implementation, say in Microsoft MVC 5/6.
A user's interaction is with the controller. Not the view and not the model. Calling an action on a controller will return something (a view, a file, a redirect, etc.).
In the case of returning a view of information, the controller, having worked out what data the user is requesting can retrieve a model that fits the request, pass this into a view, and return the view result of this model.
In the diagram above it isn't clear that the controller is acting as the agent in moving the model into the view. the model does not decide on the view. Why? Depending on what is in the model returned the controller, a different view might be returned. That is why the controller is aptly named. It sits at the centre of affairs making decisions and moving objects around.
So what you are missing is some context about how the process of MVC occurs when implemented