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.
Maybe so, maybe not. It's simply irrelevant. A hidden API is, well, hidden.
In my mind, it is relevant for the same reasons why C is relevant to C++, and C++ is relevant to C. There will always be people in both camps which don't care. I care, because I do want to be able to use existing C libraries, even though they would have been better implemented in C++.
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?
That's it's not good C++. We are designing a C++ interface here, and we want to take advantage of all the nice things C++ has to offer, as Sohail pointed out.
If you are refering to design differences between N2178 and N2184, I don't think they have anything to do with pthreads. These differences express the different opinions of the authors.
N2184 is better at using all those nice things, IMO. I don't want to damage that for this compatibility. I just don't think it worth it.
How does using pthreads as a lower level implementation for N2184 "damage" it? Emil Dotchevski