Our current statement of support is that we support enough of C99 to unblock commonly used libraries. We support a large swath of C99 but it is correct that our support isn't complete yet as we prioritized C++ conformance. If there is a C99 library that you need to use that we don't work with, please let me know. (I'm the VC++ dev manager)

It seems that MSVC really has improved its support for C99, though, and I'm glad about that. What about C11? Does it support _Atomic/stdatomic.h? I can't tell from Googling, and I'm too tired to install the CTP tonight... If it does, it'd be ahead of OS X, hopefully not for long. The C11/C++11 memory model is powerful, way nicer to use than volatile plus OS-specific library functions, and, compared to other features, it's difficult to properly implement as a shim. It's too bad that only C++ can take advantage of it on some platforms.

Existing libraries are one thing, but when writing new code (and yes, I want to write new code in C), one of the big three compilers not supporting a feature is strong motivation not to use it... even if it would be really nice to have. Maybe in the coming years Clang will improve its Windows support enough that I can just tell everyone to swap it in for cl.exe, so I won't have to care about MSVC's standards support, but for now it and GCC are missing a lot of features on Windows.

The C11 Standard Library has not been incorporated into any C++ Standard (not even the C++17 Working Paper as of right now), so we have not attempted to support it. On the other hand, our C++11 <atomic> implementation has been significantly improved in VC 2015.

I believe the choice was to spend time on adding C99 support, vs spending more time on C++ support. C++ had more people asking for it, so it got priority over C99.

Doesn't the latest C++ standard more or less include C99?

Only the C99 standard library. The language changes which weren't already part of C++ weren't imported.