There are two differing concepts here, and we don't have a great set of agreed upon terms for them, but for the purpose of my response I'm going to use "bucketing" and "stacking".
"Bucketing" is a "by-wiki" collection: all notifications from a specific wiki go into the same bucket.
"Stacking" is a "by-type" collection: all notifications of the same type go into the same stack.
The current design (as shown) operates on a bucket-primary, stacking-secondary process. That is, notifications are bucketed first, and then stacked within those buckets.
If I understand you correctly, you are asking for a "stack first, then bucket" ordering. There's some merit to that idea; I like it a lot for the use case you're discussing. I'm not advocating a change, however, since the reason we chose "bucket, then stack" is a technical one. It is going to be significantly faster and more accurate to bucket and then stack, because each "bucket" is actually going to be a single api call, which can be loaded and stacked independently. To do a stack-then-bucket process, we'll have to do multiple API calls to multiple wikis before we sort and stack the notifications (which will have to be done client side, in this instance).
I should point out that we are in the very earliest of stages for this feature, and we are still doing research as to the best design we can create. So it may be we do a stack-then-bucket, or that such a thing will be configurable (though probably not: I'm adverse to adding preferences for changing interface behavior).