That's not true at all. I have a QAbstractItemModel that represents a tree-structured underlying C++ data hierarchy. When I display that in a tree view, I use the bare model, which reports to the tree view that it has either 3 or 4 columns, depending on the level in the tree (branches have 3 columns, leaves have 4). I use a proxy model to flatten this tree into a table, and at the same time add 15 columns to each row. The extra columns represent details of the underlying data that aren't shown in the tree view. This works fine. The QAbstractItemModel that is the source model for the proxy doesn't know anything about these extra columns, so it has no persistent indexes that can be messed up.

I even add more proxies where this table-shaped proxy serves as the source model to pull out individual columns for plotting in charts and graphs. This works fine, too. On top of that, there are selection models for every view that when, for example, something is selected from a chart, the corresponding items are selected from the table and the tree.

The table-shaped proxy model does keep persistent indexes for the source model to aid in mapping, but these are updated every time the source model is updated so there is never a possibility of the source and proxy getting out of sync. Likewise, the proxies that pull data out of the table proxy automatically update too. You just have to make sure that if you implement a custom proxy, it responds to all the signals issued by the source model when something changes.

As for a strategy for implementing this, I was thinking that using a proxy that represents your table as a tree might be suitable. The group-level headers would serve as the parents for each of the items that appear in the group below it. The proxy would essentially examine the source model to identify the rows that belong in each group, and create QModelIndex parents for them.

I do not know what an out-of-the-box QTableView would do with this - it might display only the parent (group) indexes, or if you are lucky, it will flatten the whole thing out. My hunch is it will only display the top-level parents, so you may have to implement a custom table view to expand the whole thing.