Isn't this a behaviour change? As logMultiprocessing defaults to True, in the common case where one doesn't change it and doesn't use multiprocessing, processName would be 'MainProcess' in LogRecords, before this change. After the change, it will be None. What's the benefit of this?

That's right. Our choices currently are:

(1) leave it as it is, then sometimes (but not often) "MainProcess" is incorrect
(2) do this and then MainProcess is replaced by None, which is at least not incorrect
(3) always import multiprocessing and then process name is always correct

• (3) is bad because we do an import which will not be necessary in the large majority of cases (ones that don't use multiprocessing). It's probably not cheap to import, though I haven't done any actual measurements (I try to err on the side of minimizing logging processing, because many people are sensitive to logging overhead and I don't feel this import would be justified for the vast majority of cases).
• As for (1) and (2), let's look at when processName would be incorrect:
  1. In a process that isn't the main process, and
  2. Although it was invoked by multiprocessing (as not the main process), sys.modules would have contained at some point, but then somehow lost, the entry for multiprocessing. There might be reasons for this:
     • The user program deliberately does a del sys.modules['multiprocessing'], or does something else to sys.modules which causes that entry to be removed. This is a very uncommon use case (cited in the issue as a theoretical possibility, but not apparently supported by an actual real-world example). In this case, I think it is better for the developer of that program to handle that case explicitly, without forcing everyone to pay any re-import price in the normal use case where sys.modules doesn't lose stuff. This was my suggestion to the issue's OP.
     • The state of sys.modules changes during program shutdown. This does happen, but all sorts of things are winding down at that point and there is no point in trying to log stuff where even things like sys.stdout and sys.stderr might not be available. So I don't believe we have to handle this case, either.

In summary, I don't think anything should change in logging itself for this issue. However, that you added a test is valuable, and I thank for you that and the thought and time you have put into this! I think the best thing to do is close that other PR, revert the change in logging and keep the test, and as long as it passes, I'll approve and merge this.

That makes a lot of sense. I'll update this PR for the test and close the other one. I think we needed to look at all options to see that none of them are better than the current state.