...dropping out of lurk mode for one comment...keeping in mind that I have not looked at the library or read a big chunk of this thread...
About the unit I/O : I've though about providing a mechanism for it but decided later to drop it. The reason is that it adds nothing the user couldn't already do just as simply.
To provide output you need a symbol. This means that you need additional arguments to your units because you can not default generate one. As strings are very bad template arguments this will add at least one line of code. However in that case the user could also simply have written
ostream&operator<<(ostream&out, meter n){return out<<n.raw()<<"m";}
and he has the output exactly the way he wants. No problems with unicode or the symbol not being just the way the user wants it.
For the input you need a list of all inputable units, symbol position, raw number formats and symbols. In the best case this would be a long template argument list that reminds an if else chain. So why not simply use an if else chain like in the unit_converter.cpp example?
I/O turns out to be something that is quite difficult to do well. There's plenty of issues like: support for wide streams, support for different domain contexts (eg: sometimes I want it to be 'm' and sometimes 'meters'), internationalization of number format, support for serialization. In date-time, there's probably more effort in I/O than any other single aspect of the library. For me, a units library that doesn't seriously address I/O doesn't really finish the job of providing a set of types for application programmers that don't require major extension to use correctly. The whole point of this should be that I can put a 'unit type' in place of an double or some native type. If I have to write an ostream operator to use the library it doesn't make it as a 'double replacement'. ...back to lurk mode... Jeff