One nit: the kernel doesn't load the loader/interpreter/dynamic linker, it just mmap's it. The loader loads itself. There's a tricky bit of code to do this, where the loader has to do its own relocations and initialization before it can do things like "write a global variable" and "call a function." You have to write that code carefully to avoid segfaults during startup (eg: you can't call a function from initializing the loader that hasn't been relocated yet). The loader is also the thing that provides implementations to <dlfcn.h>, which is why you can't dlopen from a statically linked executable - you don't have a loader.

The other thing about the loader is that it's also libc. Most languages don't ship their own loader and rely on the platform's libc (basically musl or glibc), because if you want ffi with C libraries you also need to play nice with their loader.

Another interesting thing about ELF that it's "calling convention" (square quotes because idr if that's what it's called in the spec, but it's how a kernel "calls" start) is two registers, the stack and frame pointer. The stack pointer is obvious, top of the stack is argc followed by null terminated argv, followed by null terminated envp, followed by null terminated auxv. The frame pointer is almost always NULL because no one uses this, but technically, it's supposed to be a callback to some code that runs after exit. So if your program logically is the stuff between main() is called and returns, the loader is supposed to fill in the blanks about what happens before main (global ctors run, global state initialized, relocations handled, etc), and what happens after. On linux at least, I don't believe this is supported or even used in practice. But it's interesting to know about.