The overall program flow in this case is:

   shell => CRT => main(argc, argv) => exit code => shell

(to me, the CRT and C standard lib are not strictly separate, although that's debatable of course)

Except none of these steps are dictated by the C standard library (some may be dictated by some libc's)

EDIT: To expand on this: You can call the code from stuff other than a shell; I'm assuming you mean "C runtime" by CRT, and some libc's may have issues without them, though usually only access to argc/argv and atexit(), and you can certainly write C without linking with the initialisation code; and while you'll of course usually enter via main() you don't have to. You decide the control flow.

CRT also does stuff like floating point emulation, loading dynamic libraries on demand instead of at load time (e.g on AIX and Windows), handling threads post C11, or runtime checks in hardened code.

The point is all of that is optional. You can - and I have - written C to be executed on bare hardware with no initialisation code, and depending on your choice of libc you can still use it (though some functionality may not be available).

At which point it is no longer C, rather a programing language that vaguely resembles ISO C.

Of course it is still C. You've just opted not to use some of the functionality.

Nothing stops you from e.g. providing your own startup code which then calls the appropriate initialisation code either.

The point being that there's no enforced inversion of control in the sense used by the article, and so calling it a framework in the sense described by the article is meaningless.

Even if we postulated the inversion of control was there, the fact you can replace all parts of it still means it does not fit the article definition.

Not from the point of view of ISO C and the expected semantics of the abstract C machine.

If you were to write a program that relies on those aspects of the abstract C machine and don't provide those aspects, then you might have an argument, in that in that case the observable behaviour would be different, but if you choose not to make use of that functionality, its presence is entirely irrelevant.

This is also massively shifting goal posts. You first wrote "At which point it is no longer C". By your argument here, e.g. the Linux kernel is not written predominantly in C. But nobody uses the term that way. If you were to speak specifically about ISO C, maybe, but the person I replied to initially did not limit it to ISO C.

As such this is also entirely irrelevant to the original argument.

Everyone knows Linux is actually written in GCC C, and Google has burned lots of dollars making it work with clang, if it was proper C, that wouldn't never been an issue.

And yet almost everyone would still agree that "GCC C" is also C, so this is entirely irrelevant to what was being discussed.

Yeah, that is why plenty people then show up on Stack Overflow with questions that prove how much they know C, versus "whatever my compiler did when I tried it out".

And this has even less to do with what was being discussed.

What was being discussed was that C without the CRT is a dialect of ISO C.

The kernel loads your program, and schedules its execution. This is basically the same as using an async framework and sending the entry point to your application.

If you're willing to extend a little, there are also signal handlers, or setting up callbacks in pthreads.

Again this isn't to be reductive, but to say this is a super common method of encapsulating irrelevant stuff. It doesn't seem to be a significant differentiation between "I'm a library" and "I'm a framework".