If so, there should be reference to it within the C standard somewhere, and I'd like to know exactly what can be said about linking C translation units with other non-C libraries.

It is implementation-defined, and therefore not described nor referenced in the C standard, precisely because different implementation can do things differently.

The only rules the C standard established are with respect to identifiers (as part of the C source code) and whether each usage of the same identifier is required to identify the same thing or not (function/object/storage location) within or across translation units. How this linkage is then actually achieved is of no concern to the C standard, and a linker (or linking step, if you will) is free to do it however it wants as long as it obeys the rules about identifier set in place by the C standard.

This would mean that every kernel ever written that has any I/O of any kind is not standards-compliant C.

Incorrect. You cannot become non-compliant by "violating" non-existing parts of the standard.

With regard to linking object/machine code that is written in other languages then C (like for example assembler). The C standard is simply unconcerned about the process of linking and how it is realized or what the actual end result will look like precisely, as long as the resulting program adheres to the behavior accurately described by the C source code.

Any code that is not part of the C source code (such as a function provided by some object/machine code written in assembler) has its behavior obviously not described by the C source code nor the C standard, and from the perspective of C is thusly undefined behavior. (In other words, neither the C standard nor the C source code itself describe nor care about what will happen when invoking a function that is defined outside the C language domain.)

This would mean that every kernel ever written that has any I/O of any kind is not standards-compliant C.

Again incorrect. Memory-mapped I/O can be done entirely in C without needing language extensions nor code modules written in other languages. Depending on the actual architecture or specific hardware implementation of some architecture, a compiler might offer additional keyword extensions or some such to provide a convenient way to define configuration parameters with respect to port configurations, memory layout, and other things right there together with the C source code, so you don't have to rely on other tools to set HW configuration parameters. (You can see things like these when developing firmware for microcontrollers and such...)

elgonzo‭ I did forget about memory-mapped I/O. In that case, am I correct in assuming that C must be informed that these memory locations should be considered volatile to avoid implementations potentially optimizing away reads or writes from them? And is memory-mapped I/O the only way to perform I/O without language extensions in a freestanding environment?

Yes, memory-mapped I/O is the only way to do it with standard-conform C in a freestanding implementation, and typically involving volatile -qualified types. (I erroneously mentioned in my previous comment that port-based I/O could be done in a C standard-conforming way as well, but that is obviously hog-wash. I confused that with POSIX -- there are a POSIX-conforming ways to do port-based I/O. Sorry about that. I edited this piece of misinformation out of my comment...)