Now do it on Mac, and windows, and dynamic and static, and install the libraries in the right place. It gets maddening.

A platform has a fixed ABI that says e.g. the first integer parameter to a function goes in register R14, the sixth one goes on the stack. If you have sixty C files the compiler is obliged to produce sixty object files which each obey that ABI for all their functions because you might stitch in some other code, not using that compiler at all, which obeys the ABI and if you ignore the rules this will unexpectedly not work.

But within a single object the compiler doesn't need to obey the ABI rule at all if that's faster.

Now, you obviously could imagine an object and more powerful linkers that had enough optimisation magic to produce the same output executable from the sixty object files, but just spitting out a single source code file is a LOT easier than making that optimisation work on every platform now and in the future.

The compiler invocation above only creates a single object file.

No, but I can see why you thought so.

The invocation above creates one object file for each C source file, as temporary files, (in a Unix system you can watch it do this with a suitably powerful syscall tracer, presumably something similar is possible on non-Unix systems but I don't know exactly how)

Then it links them and produces the output you've mistaken for an "object file", then it deletes the temporary files.

Ah, probably the easiest way to deal with some translation unit edge cases. :(