I don't think that's how MVVM is implemented within development projects, as it diverges from the established architectural nomenclature.

The reason why we don’t have separate viewModel per screen is due to the drawbacks that I mentioned in my above comment.

Such dull implementations are like driving a car and bumping into someone and blaming the car for not stopping.

The entire rational of your explanation (which I am very thankful of) is depending on a situation where we have such dull implementation of MVVM.

Looking at the code of the MovieStore it appears to align more closely with the essence of a ViewModel.

In my gist, the same ViewModel can work like the MovieStore unless there’s a striking difference or gotcha that I missed.

MovieListScreen -> MovieViewModel

AddMovieScreen -> MovieViewModel

MovieDetailScreen -> MovieViewModel

The choice of calling a viewModel something else can indeed be a matter of personal preference, whether it's referred to as a "Model" or a "Store."

However, upon closer examination of the code and its associated responsibilities, it becomes evident that it aligns more closely with the characteristics of a ViewModel.