You speak as if you have never heard of Carl Hewitt's research, Erlang or Elixir before.
I wasn't aware that Erlang did IPC implicitly.
The real issue is that Erlang is its own world. But you could also say IPC is its own world (does not work natively on the Internet, does not work on non-UNIX machines, etc.)
The point is UNIX is too low-level for communication primitives. Maybe it's time to research new paradigms? It's been 60 years.
Besides, no matter how you design the system, there will be a categorical difference between communication which is expected to be fallible and communication which is expected to be infallible. The "communication" between a caller and a callee is expected to be infallible, for example. Communication between threads in a process (in the UNIX and Windows model) is expected to be infallible.
Communication between an app and a system service is expected to be fallible; at the very least, the system service has to expect that the app might misbehave in any number of ways, even if you argue that the app should expect the system service to be perfect.
In Windows there are fun things like COM apartments, owner module scopes, local RPC, wrapping in-proc COM into DCOM remoting.
Apple and Google have similar local RPC features coupled with multithtreading.
IPC must also be language-agnostic, which means serialization and deserialization, which means there will always be some manual "impedance matching" between your program's domain model and the IPC protocol's messages.
Could things be better? Sure, yeah, I guess. Languages with a single implicit event loop and with native support for JSON-like trees of values (such as JavaScript) will have an easier time than languages with neither (such as C++). But I don't think there's really some magical 10x better solution out there if only we had all "seen the light" and used SmallTalk.