Unexpected order of modelReset() signals

I just hunted down a crash in one of my classes. I derived a custom filter proxy model from QSortFilterProxyModel. I also wrote a special filter panel widget which is tightly coupled to the QSortFilterProxyModel derivative. A QAbstractTableModel derivative serves as a source model. A QTableView is attached to the QSortFilterProxyModel derivative.
 
The filter widget connects a OnProxyModelReset() slot to modelReset() signal of the QSortFilterProxyModel while the QSortFilterProxyModel connects a OnSourceModelReset() slot to the modelReset() signal of its source model.
 
All works fine until the underlying table source model does a reset. Then it happens that the OnProxyModelReset() slot is executed before the OnSourceModelReset() slot. This is fatal since the QSortFilterProxyModel of course must adapt to the reset ahead of the widget.
 
The following test snippet demonstrates the problem:

QStandardItemModel* m = new QStandardItemModel();
QSortFilterProxyModel* f = new QSortFilterProxyModel();
f->setSourceModel(m);
  
CHECK_TRUE(connect(m, &QStandardItemModel::modelReset, this, [&](){ qDebug() << "QStandardItemModel::modelReset"; }));
CHECK_TRUE(connect(f, &QSortFilterProxyModel::modelReset, this, [&](){ qDebug() << "QSortFilterProxyModel::modelReset"; }));
// Connection order does not matter (different senders!)
  
 m->clear();

 This prints:

QSortFilterProxyModel::modelReset
QStandardItemModel::modelReset

I expected the opposite order.

I consider this is a bug since the signal emissions need to correlate with the object hierarchy (i.e. data->sourceModel->proxyModel->panel+view).

Remark: It could be worth checking if other cascaded signals are emitted that way as well.