However I disagree that users like to spend time making their own units. Quan has a fair number of units supplied(still nowhere near enough though) and when they are available they are very much more convenient to use. Also I/O is useful. The original idea for this library was based on a real world example that you certainly can't have in your library.
Consider a function grapher with a GUI and a scollable view of the graph. How many different types of vectors (=points) do you have? There is "mathematical" vector, meaning the solutions of the equations. Then there are those in virtual screen coordinates, meaning a scroll undepand pixel fixed version. The relation between "mathematical" vectors and virtual ones varies with the display setting of the user so you can't hard code the realtions. And there are the scroll relative vectors or also client area vectors. These are the 3 I though of when designing the app. Later I dicoverd 2 new ones : The scroll position and window relative coordinates. You could also add screen relative if you want to. I doubt that you can provide a simple to use interface to differenciate these 6 units of vectors. Another example would be games with an isometric grid. You will spend a lot of time mapping vectors from grid coordinates to screen coordinates and back. However you do have a point that it might be better to provide stock types. For example the length quantity. It would make inoperation of code more easily. An alternative would be to provide a sort of quantity cast that allows to bypass the type check mechanism at junction points. The first option sounds better but the later is in my eyes more realisitc as you will always forget at least one quantity.
I looked at how I would do the basic.cpp example in Quan. Note that the units output comes in very handy here and also note the use of the predefined units, which saves a lot of time and effort creating units.
The basic example is also meant to be elementary so you can implement it obviously better with elementary stock types. However how often do you calculate the cinetique energie in real world examples? 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?