That said, I believe that the review for this particular library is flawed, and I question the decision to accept.
There are an insufficient number of reviews, the scope of the library is not clear, and furthermore there is no clarity with respect to answering the question "what belongs in Boost?" Ask five different people on the list and you will get five different answers. If there is no documented explanation of what belongs in Boost then the outcomes of certain reviews are going to be highly unpredictable, especially those where there is controversy.
Should I have rejected boost.url, which had the same amount of reviews? There are more libraries with seven or less reviews in boost, boost.lambda2 had 6. If we introduce a lower limit, Also, isn't a "REJECT, I don't think it belongs in boost" a fair review?
In some cases the answer to what belongs in Boost is obvious. Implementations of standard library features for older versions of C++ are an example of something that obviously belongs in Boost. A library modeled on an existing 3rd party library but polished up to Boost quality and working with other Boost libraries (e.g. boost::system::error_code) is another: Boost.JSON.
Why is the second obvious? I also find the question "does it belong in boost" misguided. If it passed review, it belongs in boost. You are free to write a short review rejecting it and the review manager is free to disregard
But then we have novel libraries for which reviewers have no template, no guidance, no existing practice to understand whether or not something belongs in Boost, and I believe Boost.Klemens.Async is the perfect example of such a library. This is my opinion, but I believe in these cases that the proper course of action is for the author to "do the work" of going out into the community and establishing a user base for the library before submitting it for review (as I have done with Beast and URL).
That's not really true. Libraries akin to async have been around in other languages for a very long time. Then there is also cppcoro and the coroutine types existing in asio. How big does the user-base need to be and how would this be measured?
Andrzej: There is a process for disputing the results of a review, by reporting the concerns to the Review Wizard. I would like to dispute the review result, on the grounds mentioned above, and if you still feel strongly about rejecting the library for the aforementioned reasons then I suggest you also dispute the review results. This goes for everyone on the list. Who is the Review Wizard for this review?
Which grounds? Too few reviews? Because all the other things you brought up should be addressed during review I would really like a review wizard to clarify what valid grounds for disputing a review are.