Of course we want Microsoft to offer this threading model to C programmers, but it's the job of the C standard committee to define the exact syntax. This standard C syntax might as well be the exact POSIX syntax, no problem by me. But it doesn't really matter one way or the other, as long as the C syntax accepted is a good one.
Doesn't this answer your original question, which was "why do we want Microsoft to ship a pthread layer"? They would have to, either way.
Microsoft might as well have to implement a pthread layer, but that's non of our business, as long as they comply with the C/C++ standard.
Except that it is of benefit to the C++ community if the C and C++ layer are compatible beyond just syntax. N2178 defines interoperability semantics that go beyond standard pthread.
The only question left is whether we want two incompatible C APIs to the same underlying model, only one of which works on Windows, or just one. It seems to me that it is in our best interest to want the latter.
We would have only one C API, and it will work on Windows. The allegedly second C API is hidden and non of us should care about it.
I would agree if we were talking about 2 substantially different APIs. Sure, if you have pthreads and something that's somewhat different, why not. The point is that pthread, with a few extensions, is exactly what we need from this hidden API. But let's turn things over: why not use pthread instead of creating another API? I think it is clear that using pthreads has a few advantages. What is the drawback? Emil Dotchevski