Thanks for the proposal. It will certainly be good to have a standard.
I can say a bit more how units are used in casacore ((radio-)astronomical C++ library with a Python interface).
Casacore has quantities (values with units) and measures (quantities with reference frame defining e.g. the zero point of time or if sky coordinates are equatorial, galactic, etc.). Note that some coordinates frames (e.g. azimuth/elevation) may depend on other data such as time or position on earth. In a table schema only constant frames are used.
It can only handle multiplicative units, thus not Celsius to Kelvin or Fahrenheit. Units are stored as strings which are parsed to determine the conversion factor. Note this takes little time as it is usually done only once to access an entire column in a data set.
The data are stored in a tabular way and each column can have a unit and frame defined in the table schema. When writing or reading the data, the unit and/or frame can be given and the data will be converted as needed. I must say that usually the data are read/written directly, thus already have the correct unit.
The table query language (http://casacore.github.io/casacore-notes/199.html) can handle units and frames and converts as needed (also useful as desk calculator :-).
I wonder if it should be considered to also support coordinate frames in HDF5. This can get quite complex though, much more than units.
A few other remarks:
Note that bytes use prefixes such as k for 1000 and ki for 1024.
I also like g much more than kg as the base unit.
I don’t see any problem in rad-deg conversion with an irrational factor. Inch-m basically has the same problem. It is more the question how precise you want to be.
I wonder how to define the units of fields in a compound data type. By having a vector value in the unit attribute?
Will the actual unit be clear to the user when seeing a string, numerator and denominator? When seeing m, 1, 1000 people might doubt if it is mm or km because they might doubt if the values define the conversion from the stored unit to the actual unit or from the actual unit to the stored unit.