MVVM Design Hickups and grey area

I have for the last few month been trying to familiate myself with the mvvm pattern in wpf. This is a topic that is widely discussed and i have come across articels which in places contradict one another. I know mvvm is a pattern and not a universal truth however do in certain case find thesse grey area of deciding what goes where, and what does what. 99% of the time it is between the viewmodel and view these problem arises.

my current mindset for deciding what belongs where:

Model: it only contains data which is to be saved to a file. Nothing More, nothing less.

ViewModel: is a communication bridge between a view and one or more models associated with that view.

View: handles visual representation, visual popups and visual modifications

first of af simple question concerning the Model: (Case 1)

In every implementation i have seen so far the model object is class implementing the INotifpropertyChanged. Why should the model be a class and not just simply an interface describing what the data should be and let the viewmodel implement this interface? The model should not deal with the ui even if it is decoupled and therfore giving a model class the INotifyPropertyChanged is just as wrong as making the viewmodel inherit from a DependencyObject (even though i understand its importance in that type of model implementation)?

Grey area example of what the ViewModel should handle vs the View: (Case 2)

Say i am creating a Uml editor where there are Nodes and Connectors Created in a viewModel and kept in thier own ObservableCollection.

<SomePageView.DataContext>
    <vm:SomePageViewModel/>
</SomePageView.DataContext>
<Grid>
    <ItemsControl ItemsSource="{Binding Nodes}" DataTemplate="{Binding SomeNodeUserControl}"/>
    <ItemsControl ItemsSource="{Binding Connectors}" DataTemplate="{Binding SomeConnectorUserControl}"/>
</Grid>

When a node is dragged around the grid any attached Connector endpoints will follow the node around as it is moved. I personally see this as Comunication between the UiElements, but there are 2 fundamentally different ways of implementing this type of behavior. Update the Connector by keeping a complete reference to the NodeviwModel and use its position members to update the position of the Connector. It is a pretty simple approach however do not like it as i believe it should be the ConnectorView that update the postion of The ConnectorVm. this requires that the Connector View know something about a specific NodeView. However this approach more complicated and i havent found a valid solution for it yet ( currently looking into the EventAgregator pattern). The Reason why i like the last aproach is that if select a connector it should be the view that dictates how the connector can be moved around and not the ViewModel. Any comments or advice on my observations?

in the mvvm pattern were should ui patterns be kept: (Case 3)

in mvvm where should the eventAgregator, Mediator be used. in the ViewModel or the CodeBehind? My current belief is they belong in the code behind, but i have a shred of uncertainty regarding this matter. If kept in the codeBehind i csn imagine a cleaner aproach by using the The VisualTree with the loadedevent instead of using constructors taking arguments of Eventagregator and likewise. Similar i can implement an UndoRedoController which would not require to be a singleton. should be easier to test, possible to have more UndoRedoControllers existing. An example could be a document program that allow mutiple documents to opened at once in tabs and therfore should have thier own UndoController.