On the other hand your way of thinking sounds a lot like what I understand Smalltalk image format to be like
That is exactly my model of the world, in fact. When linking incrementally, you don't want a tightly packed object file where the functions are stacked right on top of one another. You want something more akin to a key–value database, where you can swap out key–value pairs without corrupting the entire file. Whether that's an object file that "symlinks" a bunch of other object files, or is one large file with easily swappable blocks (like a SQLite database) probably involves evaluating tradeoffs that I don't have a lot of context on.
(For example, one benefit of keeping it all in one file is that you can send the binary to someone else or move it to another path without corrupting the file.)
That is kinda my point, we already have one perfectly good kv-database in the form of filesystem, so why not use that
We have a lot of container formats. Movie files incorporates video, audio streams, subtitles. MP3 files contains ID3, ID3v2 metadata. JPEG - Exif, PNG - metadata chunks, HTML - <script>, <style>, <meta>. ISO 9660 is a folder. ZIP is a folder with compression. DOCX is ZIP. These can be represented as folders and I would argue some users would like it a lot.
We use modules as files in python and ruby, yet it is a problem and docker solves it.
Zig specific - I do not think you advise to create library file for each function. As such it'd solve nothing - they'd have to patch libraries. And maybe they already have do that.