I see a few places in supplementalData/unitPreference where SI units with different prefixes are combined (or so it appears, I find no documentation about this), apparently for expressing a single value. If "m cm" means "choose either 'm' or 'cm'" (like "1.56 m" or "156 cm"), but no combination (i.e. NOT "1 m 56 cm"), then everything is fine. However, I have a nagging suspicion that that is not what you intend.
Combining SI units like what I think you mean is just wrong. Badly, badly, badly, badly wrong. A big NO-NO-NO! Sure, one can do arithmetic with values with units; e.g. 1.40 m + 25 cm = 1.65 m = 165 cm.
BUT, something like 1 m + 20 cm does *NOT* make any sense. The "1 m" has meter precision, i.e. the value can be roughy anywhere between 0.5 m and 1.5 m (even though it is common to *say* "one" when referring to "1.0" or "1.00", in a less formal context), adding a few centimeters to that does not make sense. 1.00 m + 20 cm does make sense, however, but it is still silly to present an arithmetic expression as the final result. The SI system has never been intended to be used in that way; so even the very idea surprises me, and it is horribly wrong to present a final result in that way. (Yes, there are more precise ways to present accuracy, but those is not commonly used, in particular never in every-day contexts. One always, in everyday use, use number of significant digits.)
Is it //explicitly// disrecommended to combine same unit but with different prefixes (for final result values) like that? No, but only because no-one thought that the unit system would be misapplied like that. Combining degrees, arc minutes and arc seconds is however recommended against (use one unit and a decimal value instead), but that is only because such combination has been used (and sometimes still is, like 34° 21.68′, note the decimals in the arc minutes part). Combining (24h-days and) hours, minutes and seconds is not disrecommended, of course, that is common use in every-day society. Still, expressions like "2.5 hours" is perfectly valid.