Hi Steven, I've been thinking about extensions to the units library, particularly ways of simplifying the use of heterogeneous unit systems (units that are from mixed systems). For example, if a user wanted to define a unit for tracking FLOPs, it is reasonable that they might want to use units like FLOPs/second or FLOPs/(second*dollar) As it stands now, the user would have to add tags to, say, the SI system for FLOPs and for dollars. What I'm thinking would be nice is to decorate the dim<T,V>::tag_type so that it carries the system with it. Then your units could be composed of any set of fundamental units. The challenges I can see are: 1) how to ensure that list of these dims are sortable; you would presumably sort on system first, then on tag: let's call SI::system -> si CGS::system -> cgs length_type -> L mass_type -> M static_rational<N1,D1> -> r1 static_rational<N2,D2> -> r2 etc... then we would have mpl::list< dim< tag<si,L>,r1>, dim< tag<cgs,M>,r2>, dim< tag<si,T>,r3>, dim< tag<cgs,M>,r4> >::type getting sorted as two separate reduced dimension lists, with si first (specific order not important), then cgs. This would make constructs like (centimeter/kilogram)*meter*gram make sense. Clearly, they wouldn't auomatically reduce to one unit system, but I think it should be possible for the explicit constructor to check that every element in the list is convertible to the desired unit system, so quantity<SI::area> a(1.5*centimeter/kilogram*meter*gram); would actually work. 2) the process of determining if a unit belongs to a system gets a little more complicated (not too bad, though). I have a couple of questions for you: any ideas on how to make tags sortable without requiring them to be specifically enumerated? this would probably up the compile-time demands. how much slower would this make compilation? Thanks, Matthias