I'm slowly coming to the conclusion that it's NOT possible to implement two separate views of the data in the document, in the way I need to implement them. The basic issue is this:

• The DomModel class I'm using to create the tree model is implemented as a "lazy" system, which means that data is not provided, and indexes are not created, until they're asked for by the view. That means that only the root elements are processed initially. That, in turn, means that the proxy model is only fed the root elements to construct its list of items with @xml:id attributes.
• Even if I were able to overcome this by forcing the DomModel to fully populate itself initially, I'm still left with the problem that the way the QSortFilterProxyModel works makes it impossible to do what I need to do. This is because filtering is accomplished through a filterAcceptRow() method, which you implement to return true or false. If I implement this so that it returns true only for elements with @xml:ids, then as soon as it encounters an element which doesn't have one, it has to return false; at that point, the children of the element are not processed. I could try to determine whether each element has any descendants which have @xml:id, but then I'd be accepting and therefore displaying a whole set of elements which don't actually have @xml:ids, just so their descendants can display.

I think the best approach is actually going to be to implement a whole different sort of structure, with two different models, built from an underlying DOM document, but encapsulated in one object. It might be easier, then, to keep the two models in sync, especially since we're expecting to allow the document itself to change; each model could be instructed to rebuild a part of itself when a component changes. It might also be easier to manage the selection issues manually in a parent object, rather than try to use the single object. I'm planning this now.