I think that we are seeking for a way to avoid shortcomings of native Win32 thread local storage, not Posix one. Maybe NTPL does not need such workarounds?
Probably I misunderstood your previous posts, but it sounded like you say that TSS is not needed at all, and should be replaced with singletons and hand-crafted thread-id -> instance mapping. I believe that on Linux, using provided TSS facilities is better, and so I need thread_specific_ptr. And to write portable code, that class should be present everywhere.
I agree, and it should be able to clean up non-boost threads as well - consider what happens if you're writing a library, and not a program - you then have no control over who creates threads or how they do so. I believe it would be unacceptable to say "you can only use this library if you also use Boost.Threads"; in such cases thread_specific_ptr is exceptionally useful IMO. John.