> My understanding is that this is specifically a problem with the Objective-C 
> runtime that _scproxy.c accesses.  The runtime is not thread safe and 
> whereas in earlier versions of macOS, it silently failed, now macOS is 
> explicitly aborting the process.

Note quite, the ObjC runtime is thread safe (and so are most high-level APIs) but a number of APIs use threads or process-level state that needs to be reset in a child proces and isn't. To phrase this in CPython API: Apple doesn't use the equivalent of PyOS_AfterFork_Child in a number of places where this would be needed to be able to use APIs in child processes.  Instead of that recentish version of macOS just detect that the process-id changed and bail out.

This is a quality of implementation issue, and could also happen on other platforms (locks held across fork(), ...), especially when using threads. 

"A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called."
<https://pubs.opengroup.org/onlinepubs/9699919799/>