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.