Looking at the reviews of Boost.JSON, a number of them fall into a
distinctive pattern: reviewers are saying "you did not implement important
parts of JSON parsing/serializing", and the authors' reply is "this was not
the design goal". My hypothesis is that this is caused by the library name.
Simple "Boost.JSON" makes a promise (at least I read it this way) "this is
Boost's response to JSON-related problems". And the library does not fulfil
that promise. In a sense, the name misguides the potential users who need
an answer, sometimes in less than 10 seconds, to the question, "is this
library going to address my need?".
Maybe the library would encounter a wider consensus if it was called
Boost.JSON_Value, or Boost.JSON_DOM. And if the first introductory sentence
in the documentation read, "this library provides a type with Regular
interface that can represent JSON contents, and provides a convenient way
to serialize and then deserialize it fast and possibly in chunks."
Alternatively, maybe we can consider the reviewed library as a candidate
for a sub-library in a more general module of JSON. Much like Boost.Math
aggregates a number of math-related components, we could treat this library
as one of a number of components in a more general Boost.JSON_Toolkit