Okay for this:
1. A moderator table to define who is a moderator. Any user added to the table is also added to the wiki-moderator usergroup. That usergroup actually gives them permissions. Conversely, for this to make any sense, moderator permissions should only apply to a user if they are in the moderator table for that node.
2. The moderator table is used to efficiently get a list of moderators when a change is made, rather than attempting to check all users for moderator permissions. When an item is added to the moderation queue, it adds an entry (or several, if the node has multiple parent nodes) to a separate queue table. If the item is no longer moderated (deleted, approved, unapproved), the corresponding entries are removed from the queue table.
3. Additionally, the moderator table contains settings that can be adjusted in the UserCP. For each node they moderate, whether to notify the moderator via email when the queue entry is created, and/or via on-site notification whenever they log in.
4. When the user is logged in, on-site notifications need to be constructed. To avoid an extra query, this will assume you actually gave the moderator group permission to moderate. First we check if they are a member of the wiki-moderator group. If they are, query the moderator table to get the nodes they moderate (where they have asked to be notified on-site) and join the queued items that fall under that node. Store the nodes the user can moderate in their userinfo in case we need to verify their permissions later. Count the number of each item type that is moderated, and output those numbers as notifications.
This is not actually done. This was an outline to make sure I had a sane idea of how to set this up without adding too many queries. Looks good to me.