Greetings, I've only begun to review the proposal in detail so the following comments apply to the proposal as a whole. "What is your evaluation of the design?" I was glad to see that the vocabulary of the program domain as defined by the authors aligned, more or less, with my own terminology. Speaking the same language is especially essential for this particular subject. The goals of the overall design also seem to align with what I would like to see in a Boost Units library. After lots of trial and error with my own design and implementations however, I believe the scope of any library accepted into Boost to fill the "units of measurement" and/or "dimensional analysis" role must be limited. The following paragraphs outline this scope. Apologies if I ramble a bit. Undoubtedly, the scope of this library should include the dimensional analysis framework which defines the fundamental types/metatypes (e.g. dimension, unit, quantity), their semantics, and their operations. It should also include only the most common dimensions such as the physical dimensions (time, length, mass, etc.) and allow, at least, other universal dimensions (e.g. currency). Other, more specialized dimensions should be defined elsewhere. The scope should not include any facilities for input and output. It should also not prevent such support however. (Input and output of units and measures can be handled by extending C++ locales with new facets. C++ locales already deal with I/O of time and money. More about internalization and localization below.) The scope should not classify units of measurement into exclusionary systems. True, many programs/programmers will have restrictions that prevent/exclude use of any units of measurement outside a well-known set of units but the other extreme is also quite possible. A program may allow arithmetic/conversions between any and all units known to the development/operating environment. In such cases, the programmer is not concerned in the least with systems of units and classification of units into systems becomes totally irrelevant (and impossible for many older and rarer units of measure). Therefore, if constraining units into discrete systems is a desired objective, it should be the responsibility of the program rather than the library. Whether the scope should include a particuar system of units (e.g. SI units, Imperial units) is debatable. Personally, I believe each system of units should be treated much the same way C++ currently treats locales. The library may contain, even mandate, a "default" set of units (e.g. SI) but including even the most common modern units is beyond the scope of the library. (Which units are modern? Which units are common?) Each system of units can therefore be defined separately as an extension to the underlying framework. I'll post more specific review comments about the proposal later. Thanks, Eric.