Thanks for taking the time to respond, compilers are always interesting to learn about!
Point 7 was (finally!) addressed by C11.
Points 6, 8, 9, 10, & 11 are all good ones that hadn't occurred to me.
It seems like points 1, 4, & 5 could be worked around, but I can see where the added complexity would be unwelcome.
On the whole, I can see why you made the decision you did. However, I don't buy points 2 (exception handling) and 3 (type support). Certainly C doesn't have these things built in, but appropriate code transformations seem to suffice in practice. For example, the CHICKEN Scheme to C compiler employs continuation-passing style [1] and Embeddable Common Lisp [2] manages to compile to C without (to my knowledge) breaking either its type system or its condition and restart [3] system.
Inline assembly is a compiler extension and not portable.
Beyond that, sure you can do whatever you want in C if you're willing to mess with assembly and non-portable memory tricks but at this point you're better off writing your own native backend. The whole point of generating C instead of machine code is to leverage the existing compiler infrastructure to support a vast number of architectures and generate efficient code. If you just dump inline assembly in a C function or rely on opaque memory shenanigans the C compiler won't be able to meaningfully optimize your code and it probably won't be portable.