Hi Andrey,
While I fully recognize the problem of new libraries acception into Boost (I'm in the same boat as you) I don't quite understand how the proposed boost_extension would be different from Boost itself. I mean, on what basis can we claim that boost_extension reviews will be more active and frequent than what we have in Boost? Consider also that Boost is a well recognized library with a wide community already, while boost_extension will be a new beginning.
There is no guarantee. But, people like me are being hold back. When gil was introduced there were a lot of people actively creating extensions. Having boost_extension might hopefully create some momentum. As, for instance, for boost::ggl there is still some momentum that could be harvest. We could even consider relaxing the rule of who can be a review manager. For me personally I would consider an active person with domain knowledge to be sufficient. Remember, extension can be very small.
Another point of concern for me is the release cycle of boost_extension. You mentioned earlier that this project is intended to be hosted on SourceForge. If I'm not mistaken, this means that we will have to set up a testing facility independently from Boost. This will also require quite an amount of additional arrangements to be done, such as a web interface with testing results, release scripts, etc.
I was hoping the people at boost could help out for the regression testing. It should be in their interest.
IMHO, such a project has a better chance to start if it uses current Boost facilities, at least at first. Perhaps, restructuring sandbox and periodical testing and releasing it as a separate package might be a good start.
Sure, the more help the better. Thanks for your insight, Christian