1) The target unit may only have one instance of each tag (no repeated tags with different systems). Otherwise, the conversion becomes ambiguous.
If the source has only one instance of each tag than it should be easy too.
But in general we should assume that constructs like this are legit: quantity<SI::volume> V(1.0*SI::meters*imperial::feet*CGS::centimeters); where the system of the result type defines the conversions imperial::feet->SI::meters CGS::centimeters->SI::meters to get the conversion factor...this is unambiguous in all cases, AFAICS.
A more sophisticated data structure might be appropriate
dim< length_tag, mpl::list< mpl::pair<SI::system, static_rational<2> >, mpl::pair<CGS::system, static_rational<1> >
I guess the problem is that the optimal data structure for compile-time algebra won't be the same as the optimal data structure for conversions. For the former, you really just have three steps: 1) append two sequences 2) sort by unit system/tag type 3) reduce duplicate tags For the latter, you really want to 1) sort source type by tag_type 2) iterate over systems, converting to destination system 3) reduce duplicate tags Seems like these two are at odds, but I may just not be thinking about it right. Also, making the data structure more complicated would, I imagine, pose a problem for compile times again... Matthias