Matthias, I'll split my answer in two parts. The more technical will follow.
A Boost library isn't mandated to completely solve all aspects of a given problem domain for all potential users.
Maybe the whole conflict is only due to fundamentally different expectations. When I read the introduction, full of words like "zero runtime overhead", "in a general and extensible manner", "generic", "arbitrary unitsystem models", "arbitrary value types", "general facility", "fine-grained control", "complete SI and CGS systems" etc then I (and I suppose others as well) get the impression that this library certainly is the definite unit library that claims to solve any unit conversion problem under the sun. Generally speaking, Boost libraries have a very high reputation to actually solve the problem they claim to solve. But this one does not live up to my personal expectations raised by that introduction. This is clear to me, but I am afraid others may take some time to discover that fact the hard way. Maybe the not the library, but just the expectation is wrong. To avoid such misconception, please give your potential users the chance to adjust their expectations beforehand. I'd suggest to add to the documentation a section like the following (not exhaustive, you will probably add other points that are important to you), clearly stating what can and what cannot be expected: "Domain of application and restrictions This library enables to specify the exact physical dimension of any scalar or fixed aggregate quantity by encoding the dimension in the respective type. The type system is able to deduce the internal type of a physical quantity from arithmetic expressions involving other quantities fixed at compile time. For storage in variables however, the user of the library will need to specify the exact type. It is believed that the library is most useful when this type system is applied to the whole program. Since the library does not allow for mixed storage of quantities e.g. in vectors, further workarounds will be necessary when dealing linear algebra like BLAS, LAPACK or other advanced numerical libraries. Because the physical dimensions of all quantities are fixed ad compile time, there is no support for code that acts on certain quantities regardless of what these quantities actually represent, i.e. all quantities specified at runtime of the software. This includes GUI frameworks, post processing or visualization tools. The library provides support for language-independent serialization by the use of Boost.serialization library. No attempt is made to ensure that the units of the deserialized quantities match the ones of the serialized ones. No attempt is made to provide formatting for quantities in human readable form (beyond debugging output). No attempt is made to provide parsing of unit input in human readable form." Does this reflect the the admissible expectations more closely? Yours, Martin.