Alfredo, As one-half of the Boost.Units developer's community (actually I should also give due credit to Torsten Mähne for contributing the lambda component), I'll try to answer your questions :

Does any body have experience with using boost.units quantity with a underlying type that are not double, e.g. multiple precision, or vector (geometric) objects? Does it work well?

For "well-behaved" types, Boost.Units should work transparently. See the examples for complex and measurement types. I believe there are some users who have applied Boost.Units to vectors in varying coordinate systems as well.

Are there future planned developments for Boost.Units, in terms of external features (e.g. automatic conversion, better interaction with boost.phoenix) or internal implementation?

Automatic conversion is a much-requested and highly contentious issue that we intentionally did not support in the library, making the decision after much careful consideration. It is difficult to do it correctly - in the situation where you have, e.g., mixed meters and feet : 1.5*meters + 3.7*feet either there must be a specified default set of units to which everything is converted or an arbitrary decision must be made by the compiler. While it probably doesn't matter too much in this case, and for MP numeric types it shouldn't matter at all (excepting execution time), there are possible unit combinations where truncation/ round-off could become a problem. There is no obvious way to determine this at compile-time. Why not just explicitly specify your default units of choice in your code - this is self-documenting and should be consistent and correct. Do you have a use case where the requirement of explicit unit specification is excessively problematic? As far as Boost.Phoenix, what are the concerns? While I can't speak for Steven, I personally do not have a tremendous amount of time or resources to devote to Boost.Units on an ongoing basis; my bread-and-butter work is in medical imaging and, therefore, Boost.Units is a somewhat tangential project. That being said, one of the beauties of the open source model is that other interested parties (you, perhaps) are welcome to extend the work. Going from code that works for your particular application to code that is Boost-ready is non-trivial, but there are quite a number of people who can help provide advice. Boost.Units.Phoenix would be, I'm sure, a great addition to the library. As far as internal implementation, what are the concerns? Best, Matthias