FIDL actually does make backwards compatibility a core concern. Being able to modify an existing type and allowing client and servers to continue to work when out of sync is achieved through a similar mechanism by which protobuf achieves it - a data type in which all members are optional.

That said, there are certainly many design decisions that FIDL does do differently because the constraints of the problems it tries to solve are different as you mention.

Skimming the docs, it looks like the heavyweight use use of "tables", much like Flatbuffers, seems to be the only mechanism for forward evolution of a protocol.

Looks like "structs" you can only remove boxed fields by setting their references to null, but not add fields.

Other types such as unions, enums, and bits also have properties that allow for evolution: https://fuchsia.dev/fuchsia-src/development/languages/fidl/g...

This difference in focus doesn't stop various teams at Google from forcing gRPC/Protobuf into use in places where an IPC system like Mojo/FIDL or even a simple wire protocol (JSON over WebSocket say) would be more appropriate. I know of at least 2 HW/embedded type projects at Google where major engineering had to be done for months because an upstream team refused to use anything but gRPC.

Mojo and FIDL aren't necessarily portable outside of their respective platforms. grpc may have unnecessary overhead when used for IPC, but it's well supported, understand, and portable. I don't claim to understand the full constraints the teams you refer to were under, but I'd like you to consider that they may have done what they thought was best.

Why would you assume I didn't consider?

Are old applications going to run on new kernels? If so, backwards compatibility is a primary goal of an IPC dialog.