There seems to be some cross-talk here about what’s wanted, let me try a worked example.
Consider a Zig application, let’s make it an image editor. This is for end users, and it’s never reasonable to expect end users to run a compiler.
Image editing is inherently open-ended, there’s always another exotic file type to convert to and from, filters are an unbounded set, and so on. Also, many, even most, of these features are computationally demanding, so it’s not so simple as embedding Lua in the binary and calling it done.
So that’s where plugins come into the picture. End users can download them and drop them in a folder, and it Just Works. Since this is a Zig-native program, it’s using idiomatic Zig: structs aren’t extern, there are slices everywhere, tagged unions, and so on.
So exposing all of the surface area through the C ABI is just going to be painful. It’s at best a bunch of extra shrink-wrapping and ceremony, which has to be carried out on the other side of the system boundary.
It’s right to want something better than this, and Zig should have it. But I don’t think the language is ready. The compiler team needs basically complete freedom to compile Zig into any object code which fulfills the language semantics, and I think that will remain true for, who knows, but awhile longer yet.
I agree that most things which are done using runtime linkage should be statically compiled instead, but not everything. But I also see it as a niche, and not an urgent feature to add to the language, so in the meantime those who want to architect code this way are going to have to go through the C ABI, and get used to writing ptr: *const u8, len: usize, a lot.
Definitely a part of any respectable Zig Maximalist platform, however.