Here is a late review.
* What is your evaluation of the design?
Excellent. The design of Boost.signals is excellent, and Boost.signals2 follows the same design. Boost.signals2 should provide an optional (non-thread safe) compatibility mode with Boost.signals. This mode should not be available by default, but only if the user defines some macro. This will make porting from Boost.signals to Boost.signals2 much smoother. Frank also mentioned the possibility of adding a thread safe version of boost::trackable based on boost::enable_shared_from_this. That would be a very valuable addition to the library.
* What is your evaluation of the implementation?
Have not looked at the implementation.
* What is your evaluation of the documentation?
I agree with the other reviewers that it could be improved.
* What is your evaluation of the potential usefulness of the library?
Very useful. The lack of thread safety is the main weakness of Boost.signals, and is the only point where Boost.signals is inferior to the Qt signals.
* Did you try to use the library? With what compiler? Did you have any problems?
Tried with MSVS 9.0. No problems.
* How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
Read the docs. Wrote, compiled and ran a few simple examples.
* Are you knowledgeable about the problem domain?
Yes. I do all my work in an event-driven framework. The three Boost libraries I use most are smart pointers, bind and signals. I also have a lot of experience with the Qt signals.
* Do you think the library should be accepted as a Boost library?
Yes. We need thread safe signals. Many thanks to Frank for submitting this excellent library, Johan Råde