Missing webhook user events - by design or oversight?

There are a bunch of actions that I would expect (and would like) to generate webhook user events, but they don’t. Before I go filing bug reports (or submitting PR’s), I’d like to get a better idea of why that is.

action expected user event
account deactivated by admin user_logged_out
account anonymized by admin user_logged_out
user logs out self via “Log out all” button user_logged_out
added to a group user_updated
removed from a group user_updated
trust level increased/decreased user_updated
moderator status granted/revoked user_updated
admin status granted/revoked user_updated
unsuspended user_updated
silenced/unsilenced user_updated
  • The first group of three are all actions that result in a global, all-sessions-invalidated logout of the user — but unlike other similar actions (e.g., user logged out by admin), these three don’t generate a user/user_logged_out event (or any other event).
  • Being added/removed from a group generates a group_user event, but not a user event. The group_user events aren’t very useful by themselves, since they only contain the internal numeric id’s of groups and users. On the other hand, the "user" record sent upon a user event contains really useful information for all the groups to which a user belongs, including the names of the groups and details about the user’s relationships with the groups.
  • When a user’s trust level is increased, a user_promoted event is emitted, which contains data which is very similar to, but not quite the same, as a user event. When a user’s trust level is decreased, no similar event is emitted at all.
  • No user events are emitted when moderator or admin status changes. (There is indirect user-specific evidence of grant actions via group_user events; there is no user-specific evidence of revoke actions.)
  • Suspending a user does emit a user/user_logged_out event (with "suspended_reason" and "suspended_till" fields indicating the suspension)… but there is no event when a user is unsuspended. No events whatsoever are emitted when a user is silenced or unsilenced.

Are any of these omissions on purpose?

My general thinking is “If the data in a user event "user" record would have changed, then a user event should be emitted.” That probably encompasses more situations that do not currently evoke events. However, the few I itemized in the table above are the ones I care about the most at the moment because they all involve changes to a user’s authorization status.