This question has arisen a few times and been discussed on other tasks: T334623, T353953.
On those tasks, we've discussed separate solutions for each feature, since CheckUser and AbuseFilter save user information and/or create logs using their own tables. However, some features log via core's ManualLogEntry (e.g. SpamBlacklist - T358806), so some solution is needed centrally.
Background
With temp accounts enabled, it is possible for a person who is logged out to do something on the wiki that results in a log being made, of which they are the performer, but doesn't result in a temporary account being made. Who should be logged as the performer?
We can't log the IP (the current status quo), because we can't save a new IP actor in MediaWiki (ActorStore throws an error).
We can't log a temporary account because it hasn't been made yet.
Possible solutions
Log the temporary user as the performer
Options 2 and 3 from T334623#9653885:
Log the IP actor as the performer
This would involve saving the IP address to core's actor table. I don't think this is a good idea, but including it here to be exhaustive.
The actor table would need to be regularly purged to remove the names. MediaWiki would go back to saving IP addresses by default (whereas without this, you'd only save IP addresses in special extensions like CheckUser and AbuseFilter). Anything that joins on the actor table would need to be updated to handle a missing name.
Define a new type of actor for unsaved temp users
This new type of actor would have a row in the actor table, but not in the user table (like IP actors, system actors). This idea is explored in T334623#9656689.
Conceptually, we do have a new type of actor: one that represents a real person (so can't be a system user[1]), who does something loggable (so must have a row in actor), but can't be an IP actor (because the IP can only be kept temporarily), and can't be a temp user (because they didn't do a $wgAutoCreateTempUser['actions'] action).
Actor/user "types" in MediaWiki are currently defined by checking their usernames (until T336176) - either by matching them to a regex (IP, temp) or a config (system), so in practice this might mean being able to recognize a new pattern. Or solving T336176 first.
[1] We explored representing these actions using a new system user, but decided that it would be confusing to have a single system user represent a very large number of actions performed by lots of real users - e.g. CheckUser checks would reveal many unrelated IP addresses for what looked like one single user, and analytics would find that one user did a high proportion of actions.
