How are we to use an object like this in XAML? Its easy enough when you control the lifetime of the object, you can use the IDisposable interface and wrap the logic in a 'using' block or dispose of it explicitly with the 'Unloaded' event. However,
I've got ItemsControls that are bound to these lists that must be reconciled automatically with the data model underneath the controls.

Thank you very much for the very detailed reply but it assumes that you override every ItemsControl that wants to use this list (or one like it). In our product we have hundreds of buttons and comboboxes and dozens of ListViews.
All of them would like to use these lists like this that collect data from the data model. The XAML generally looks like:

So, you see, it isn't alway practical to override disposable behavior a control. We would need to do this to every control that is to use data collected from the data model. I think I know the answer to this one, just wondering if anyone's
come up with a clever way to user IDisposable in an MVVM architecture.

The issue is that my resources are not always related to a control directly. Sometimes they are part of a view. In the above example, I might have something like:

<ListView ItemsSource="{StaticResource myCollectionView}"/>

The solution above is a nice one, but it assumes that all IDisposable controls are used as the DataContext of the control and that we can re-engineer all the controls to handle the Unloaded event.

I think the right approach -- and I'm still working on this -- is something similar to Pete's answer, but less generic. I think I'm just going to have to bite the bullet and write the "OrderType" ComboBox so that it manages the list that's tied to
the data model. There doesn't seem to be any hope for a generic approach for using IDisposable objects from XAML.

This is the issue: This particular view model must have event handlers installed in order to keep the view model reconciled to the data model. When the view model goes out of scope, those event handlers need to be cleaned up (that is, the handlers
in the view model need to be disengaged from the data model). There is no mechanism to do this deterministically in C# (such as the explicit destructors in C++). The IDisposable interface was build for explicitly cleaning up managed resources,
but there is no method of calling IDisposable when the view model goes out of scope.

The option suggested by Pete above uses the 'Unloaded' event of the control that 'owns' the view model. This will work except that we've got a huge number of generic combo boxes, list boxes, and other ItemsControls that were all designed using just
XAML. This is a VERY powerful concept. Now we will have to make specialized combo boxes (e.g. a specialized 'Order Type' combo box) that exposes the view model as a property. These specialized controls can use their 'Unloaded' event hanedlers
to call the IDisposable interface.

It is a real pity there's nothing built into the architecture to see if the object is an IDisposable when it goes out of scope and immediately calls the interface (or some such similar device).

XAML in the View describes layout and binds to a property of Viewmodel which is set as the datacontext for the view.

Viewmodel exposes list(s) of objects. Containing data and commands. There would be one property which is a typed list per collection. So you have 4 listboxes then you expose 4 collections from the viewmodel.

Updates are notified between whichever lists and the a repository via messaging.

The View instantiates the viewmodel.

The view goes out of scope and the viewmodel goes out of scope with no events to mess things up.

Why did you propose Andy's post as an answer? It speaks in generalities without any specifics. XAML_Guy's post was closer to a usable answer. As far as I can tell, the real answer is that this is a flaw/feature of C#. The IDisposable
was created to deal with cases where you need an explicit destructor. In the old days you would do the same thing by deleting the object explicitly. XAML_Guy's pattern will work, but involves re-architecting many of the controls we're using.
I'm also looking at using the IWeakEvent interface to accomplish the same thing.

I followed it all, I just don't believe it's a proper implementation of MVVM.

I had a specific question about the implementation MVVM and was looking for an concrete answer that I (and others with the same problem) could implement, not generalities. The code left by XAML_Guy partially met my needs: the Loaded/Unloaded events
seem like part of an answer, but it means I need to get rid of the shared data models created by statements like:

And bury the collections inside each control that wants to use them, using the Loaded/Unloaded to dispose of the event handlers required by 'myCollection'.

In the example above, I would have to change the generic 'ListView' into an 'OrderTypeListView', and that's the rub. We have dozens of these generic controls that work in many different scenarios with just a little templating. Using a pure MVVM
approach, I'm going to have to change each of the generic controls into into specific ones that incorporate the data model. I suspected this was the direction I would have to take but I was hoping there was an easier way. The IWeakEvent pattern
works also, but I've decided that if you're in for a penny, you're in for a pound.

I've bit the bullet and am rewriting all the generic controls to use a pure MVVM approach.