Impossible to do without creating infinite loops: get_member was designed to return the SU'd member, and we cannot rely on GLOBALS because keep_su_strict will prevent us from knowing which staff member did the SU at all. Changing any of this will bug-up sessions and member cache.

I know this is closed, but I wanted to write that I'm not a fan of this one for a couple of reasons:
1) It's always going to be the case that user data could be accessed without them knowing, so it's creating a false sense of privacy by giving a partial picture. Someone can always just look in the database, and in the real world it is going to happen because people look in databases and can't help see what they see. Staff could also always hack the code to remove the feature, so as a user I would also not necessary trust the notification as being particularly accurate.
2) I don't like the basic conception of the implementation. It's hard for me to communicate exactly why I don't like it, but it resolves around some combination of rushed staff just doing boring innocent admin stuff (like checking to see if there's a bug), combined with potentially trigger-sensitive users who respond badly to stuff they don't really understand. I think it's reasonable to try and achieve a balance because "not scaring users" and "not inconveniencing staff" are just as legitimate design considerations as "informing users about data", especially when no data was actually accessed.

I am going to create a new issue that is similar but I think more reasonable and manageable.