Much of the above abuse would get flagged by -Wconversion.
Some would, sure. But some things, such as weakly typed enumerations, are standard behaviour and don't tend to trigger warnings except maybe in Lint-style tools.
Good luck writing device driver code without [pointers], though.
I'm not saying you don't need explicit pointers. I'm saying you don't need, for example, those pointers to be nullable by default. I have done my share of embedded work, and I have yet to encounter a situation where accidentally dereferencing a null pointer was a good thing. :-)
Most modern languages either aren't much more strongly typed than C.
I didn't say most modern languages are good, nor did I claim that most modern languages are suitable for systems programming. I don't believe either of those things to be true. In fact, if there's one recurring theme throughout my comments in this discussion, it has been that we are far too willing to put up with existing inferior languages, mostly because of momentum and non-technical issues. I believe that this is holding the industry back from creating and using better languages, even though we have vastly more experience about how to do that now than the creators of languages like C had at the time.
On the other hand, the more complex memory models don't come for free.
No, they don't. At the very least, they add a degree of complexity to the language.
We've long since learned how to avoid mismatched malloc-free pairs in most of the programming world, even if C hasn't. That's the easy stuff, and personally I think it's absurd that we're still using any programming languages that don't provide those kinds of tools one way or another. Today's problems are more about things like out-of-order execution and concurrency. Fine control of things like memory fences for synchronising access to shared or volatile (as in, externally influenced) storage is necessary to write safe code on modern architectures.
There have been several people in this discussion -- though I'm not saying you're one of them -- arguing that C is suitable for systems programming where other languages aren't because it's so transparent and predictable. But the reality is, there was a lot of very detailed discussion happening around the turn of the decade in the C and C++ worlds about these issues. Despite the resultant updates to the standards, plenty of code is still being written that doesn't fully take these issues into account, and plenty of legacy code is still being used that was written before these issues had been formally considered and standardised. So I don't really buy that whole simplicity/predictability argument, nor do I buy that the overheads of doing better are prohibitive. Doing better is necessary to write correct code on a lot of modern platforms, whether it's convenient or not.