Could prioritize it last and only do stuff if mod_res == mod_res_deny or something.

In that case, the module being overriden will send out reject messages

It appears to be for any listmode (+g, +e, etc). I noticed that you didn't specify this.

I'm having trouble replicating this against the current 2.0 git. Is it still an issue for you?

I just updated my net to current 2.0 git a few days ago and still see this. Joining user's client requests ban list (allowed) but as override capable oper, it's shown as override. Not just on join, /mode #chan b will trigger the override notice too. Yes, a regular user is allowed to view the ban list on my net (verified).
I believe this is what #1418 is for.

I just ran into this issue as well. One network logged an override, while the other didn't. It turns out the difference was in the <type:override> setting. On one network its set as <type:override="*"> and on the other its set as <type:override="INVITE KEY LIMIT BANWALK">. The first one with * logs the override, while the latter one with the list of overrides does not log an override when doing a /MODE #channel b, but that is because it does not have MODE in that list. This of course makes perfect sense but was confusing me at first as indeed no override should be logged for simply viewing listmode lists.

However, upon reading the thread of #1418, for opers that do have MODE (or *), this should still be logged for modes hidden with <security:hidemodes>, as appropriate.