You are right, the class QProxyModel is obsolute, but it's cousins are not. Proxy model is a bit of a generic term. I'd recommend you base your proxy off [[doc:QIdentityProxyModel]] if you're using Qt 4.8 or up, and QSortFilterProxyModel otherwise. I usually #ifdef the base class for such proxies based on the Qt version, so the class will work in either case.
If a whole column represents the same PQ, then I'd considder giving that (and the unit) information as a role for the header, as well as as a role for each individual item. The latter may seem a duplication, but it will make it easier to get the PQ and unit if you just have a QModelIndex to your data. In your proxy, you can use the knowledge to set up a simple mapping per column. Perhaps something like this:
if the source model for the proxy provides a PQ and unit for the header of a column, use that for all items in that column;
if the source model does not provide a PQ and unit for the header, try and see if there is a PQ and unit for the item itself. If so, use that;
if not, do not convert.
That way, you can set up a default mapping for basically all your data by iterating over the headers of the source model once, avoiding endless calls to find out the PQ and unit for each item every time. However, you're still flexible to change in case you decide that your source data for a particular column is not uniform.
For using multiple views on the same data, using proxy models is perfect. You'd give each view its own proxy model, set the unit system on it you want, and set the same base (SI) model on each of the proxies. That way, all views view the same data, just with their units converted.
Multiple header rows is going to be complicated to achieve.
