One issue with these discussions is the all-to-frequent mixing of different architectural viewpoints in the same discussion or diagram.
- Some architectural viewpoints are meant to show depth: deep dives into how some particular functionality is implemented.
- Whereas other architectural viewpoints are intended to show breadth: the interactions of components that are peers (that exist at the same level in terms of depth).
Mixing both viewpoints (depth and breadth) together in the same diagram tends to lead to confusion. In surveying the sources your citing, I find no shortage of this kind of mixing of these what would more ideally be separated architectural viewpoints.
For example, the diagram you're showing (citing Microsoft), you have said MS claims to be an MVC diagram, but it is primarily showing depth in the domain model, with overweight focus on persistence (from the MVC perspective). So, this diagram is weak on the breadth viewpoint of interacting peers (M,V,C) and mixes in some depth viewpoints with persistence: broken out (and elevated to be a peer of the other components). It is understandable that one might question where the domain-logic belongs given the-all-to-easy-to-mix architectural viewpoints.
In MVC, the model is what is responsible for maintaining domain objects, responding to domain-oriented queries & commands (including validation, etc..), and enforcing/effecting domain-oriented rules & behaviors. MVC doesn't speak to breaking out persistence: if your system includes persistence that is an implementation detail (detail of depth, not of breadth). Thus, there is no question as to where domain-logic belongs in MVC, or whether domain-objects should be dumb or smart — these questions are all internal aspects (implementation details) of the model.
You are also correct that the term Model is overloaded and over used. So, what the term means has to be evaluated in some context. Unfortunately, many of these discussions fail to set or keep context, adding to confusion.
In MVC, the term Model means what I mentioned above (keeper of domain objects, handler of queries & commands..). We might speak of POJO's, and such discussion should apply to the interactions between the peers M,V,C, and whether the query & command interface to the model uses dumber or smarter objects.
In detailing persistence — an implementation detail from the MVC perspective — we can speak to POJO's, or smart/dumb at different places in the persistence mechanism, we can even reuse the term model at different interfaces in the implementation details of persistence.
In summary, it is possible for the term model to be used in both ways you're describing — it is not either/or. What makes things confusing is that we often fail to set context, and/or fail to show when we're shifting context from breadth (interacting of peer components) to depth (implementation detail of usually of one of these component).