Since these are just different units for the same dimensions, I don’t think they should actually be restricted anywhere. It should be possible to just say (Versta::new(5) / Microfortnight::new(2)).unify().into::<MetersPerSecond>() and get the result. This would require to have associated conversion factor in the unit declaration, but that should be easy.
It would be perfect to eventually support even Meter::try_from_str("2 nmi") resulting in Meter(3704), but to make that extensible, there would have to be some global registry of unit parsers (support for global registries of factories and/or static instances would be a useful general extension for rust).
Also as insane as it may sound to us who learned to do physics in SI, there actually still are people who do engineering calculations in imperial units, often using either slug for weight (with force-pound) or poundal for force (with mass-pound).
The representation is a paremter, that’s not a problem. It would want to support dynamic conversion factors though.
This, however, means, that every user will have their own system of dimensions. Because one will have just length and the other will have parallel length and perpendicular length (the ratio between them is angle). And yet another may have just one dimension for both length and time, because they are using natural units (where c = 1, dimensionless).
The unique constants that Boost uses only need to be unique in such system and then everybody either uses the predefined one, or defines their own that is independent of the others, so it’s not that big problem. It does make things simpler if you can combine the systems freely though so I am not saying the constants don’t complicate anything.
Some values cannot be multiplied or divided (e.g. ºC, ºF, pH, dB). We do not attempt to differentiate between units that can be multiplied/dived and units that can, although this might happen in a future version.
This is not, actually, about units at all, but about positions in a coordinate system. The time on the system clock is in seconds, but dividing it does not make any sense either.
Therefore I think the correct approach is to have a separate value type (say Position), where the operators defined are restricted to Position + Measure → Position, Position - Measure → Position, Position - Position → Measure (and comparisons).
Then °C would be just special in that it would be a unit for Position only and its corresponding Measure would have automatically unit of K (Kelvin). In fact, the unit would probably be K in both and the °C would be special alias when combined with suitable declaration of “coordinate system” in the Position.
This is how std::time::SystemTime and std::time::Duration work and for adoption it would be great if those became Position and Measure.
This does not apply to pH and dB, where the reason multiplication makes little sense is they are not linear (so addition still does make sense, unlike °C, or wall times), but those are much more corner cases.
