Edit: I say this because fuchsia seems to be an attempt to build an OS from scratch. Introducing a new IPC layer built specifically for the permissions-based language agnostic model of the zicron microkernel will make cross language/cross application interoperability way easier.
Sun RPC, DCE, CORBA, COM, D-BUS, gRPC, AIDL, XPC,.....
DCE's RPC and IDL were derived from Apollo's NCS RPC and IDL.
I'm unaware of a direct link between NCS and Mach, but Mach's RPC and Matchmaker IDL (and the 'mig' tool) I think pre-dated NCS? Ironically, they're the basis for Apple's XPC today.
I'm old :-)
DBus as well, but DBus is horrible.
Instead of creating a new language for interface definitions; why not just use an existing general purpose language? C++, Objective-C, Java, TypeScript ...
Or take this new language you have created and extend it with control structures and other basic language features, and write the OS in that.
In my opinion Oberon (and similar) is an example of a fundamental massive task (building an OS from scratch) actually becomes easier if the scope of the task is expanded (by creating a language suitable for the task).
Google has so many resources and so many dispersed projects that individually are world class (virtual machines, programming languages, UI design, OS microkernels etc.) but they don't bring them together to a coherent something that really could bring things forward.
This is the curse of being a big company. Google is not unique in this sense. I remember a conversation I had with Cory Doctrow few years back. I met him at Cambridge's(UK) Judge Business School where he was giving a lecture to promote open-source ideology. After the lecture I was walking back home and he was going to the bus-stop. So we started chatting, and I bragged about my employer telling him that my company has open-sourced its Operating System. He looked stunned and asked "Which company??". I said Symbian :) And he said, "Ah! Nokia!" :) And then he pulls out an N95 out of his pocket and says "Nokia makes fantastic hardware, but look at the software! You can't even find a menu item. One has to press 2-3 buttons to just find an app." Then he pauses as says, "I visit Nokia, and meet lot of people there. They have some of the smartest people. You talk to them individually, you realise how smart they are." And then he waves the N95 and says, "But you put them together, and they come up with this!" :) I understood what he was saying!
The UI uses Flutter.
Surely you can find a general purpose language that gives you that ...
Hashicorp HCL2 might also be, but I don't know if they are turning-complete off the top of my head. Some blog suggests it actually is TC, but I cannot corroborate.
Starlark/bazel is TC.
You can add Berkeley Packet Filters and BLooP to the list of TI languages: https://www.quora.com/What-is-an-example-of-a-Turing-incompl...
Now maintained by independent developers.
To clarify slightly: Encoded Protobufs cannot be mutated in-place at all. You have to parse into language-specific in-memory objects, mutate those, and then serialize again. Cap'n Proto does support in-place mutation, with the caveat that if any object changes size, it'll be moved to the end of the message, leaving behind a "hole". You can "garbage collect" the holes by copying the whole tree into a new message, which should be much less expensive overall than parsing and serializing the whole message as Protobuf would require.
If you could convince multiple languages to share the same notion of a heap (including how to malloc() and free() memory), you might be able to get closer, allowing for truly mutable objects without the caveats Cap'n Proto has. However, memory allocation is a major place where languages tend to differ wildly.