I think all desired modifications can be proposed in the current Boost Thread rework effort and aren't too intrusive. For thread launching I prefer Kevlin Henney's proposal approach. Has the committee rejected this approach?
You are not alone. The problem is that Kevlin is a very busy man, and has not yet produced a full working proposal. Likewise, I am not aware of a freely available reference implementation, whereas there are at least 3 known separate implementations of the Boost threads interface.
There is a partial implementation (threader, joiner and lockable) I wrote some months ago: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming See thread_ex.2005-08-31.zip. It's constructed above Boost.Thread. I didn't know then Boost.Thread's had unlock() function so I had to make ugly things to access Boost.Thread's mutex private functions. But the thread launcher is implemented with Boost.Thread and shared_ptr.
The approach has not been rejected, but is unlikely to make it in time for TR2. Likewise, the thread library itself is most likely destined for TR2 rather than C++0x, although I believe the evolution group would prefer us to be more aggressive on this.
We can implement thread launching interface above Boost.Thread, as in the wrapper I wrote. Using that wrapper to launch threads and condensing 6 mutex types into 2 it's possible for TR2. We can let read write mutex (or shared_mutex, if you prefer that name) for C++0x along with a message queue. I will look to Pete's paper to propose changes to Boost mailing list (including Howard Hinnant's lock reduction).
TR2 is shaping up nicely as a library offering system-services though, with FileSystem accepted, and threads and networking strongly under consideration. Beeman's approach to error reporting for system-specific errors could be broken out of FileSystem and become the underpinning mechanism shared across all TR2 system-level libraries.
I'm trying to follow also that error reporting system with Boost.Interprocess, and I must say that I find that approach good in general. Regards, Ion