CLDR-14305 Small cleanup for total order in unit normalization (unicode-org#5075)

Author: macchiati

docs/ldml/tr35-info.md

@@ -1138,19 +1138,22 @@ The unitType (as in “length-meter”) is not the same as the quantity. It is o
 
 ### <a name="Unit_Identifier_Normalization" href="#Unit_Identifier_Normalization">Unit Identifier Normalization</a>
 
-There are many possible ways to construct complex units. For comparison of unit identifiers, an implementation can normalize in the following way:
+There are many possible ways to construct complex units. For comparison of unit identifiers, and for formatting, an implementation can normalize in the following way:
 
 1. Convert all but the first -per- to simple multiplication. The result then has the format of /numerator ( -per- denominator)?/
    * foot-per-second-per-second ⇒ foot-per-second-second
 2. Within each of the numerator and denominator:
 3. Convert multiple instances of a unit into the appropriate power.
    * foot-per-second-second ⇒ foot-per-square-second
    * kilogram-meter-kilogram ⇒ meter-square-kilogram
-4. For each single unit, disregarding prefixes and powers, get the order of the _simple_ unit among the `unitQuantity` elements in the [units.xml](https://github.com/unicode-org/cldr/blob/main/common/supplemental/units.xml). Sort the single units by that order, using a stable sort. If there are private-use single units, sort them after all the non-private use single units.
-   * meter-square-kilogram => square-kilogram-meter
+4. For each single unit, disregarding prefixes and powers, get the order of the _simple_ unit among the `unitQuantity` elements in the [units.xml](https://github.com/unicode-org/cldr/blob/main/common/supplemental/units.xml).
+Sort the single units by that order, using a stable sort.
+If there are private-use single units, sort them after all the non-private use single units, in alphabetical order.
+   * meter-square-kilogram ⇒ square-kilogram-meter
    * meter-square-gram ⇒ square-gram-meter
-5. As an edge case, there could be two adjacent single units with the same _simple_ unit but different prefixes, such as _meter-kilometer_. In that case, sort the larger prefixes first, such as _kilometer-meter_ or _kibibyte-kilobyte_.
-6. Within private-use single units, sort by the simple unit alphabetically.
+5. As an edge case, there could be two adjacent single units with the same _simple_ unit but different prefixes such as _meter-kilometer_.
+In that case, sort a sequence of those units by the larger prefixes first, so … megameter < … meter < … picometer < …
+     * meter-kilometer ⇒ kilometer-meter
 
 The examples in #4 are due to the following ordering of the `unitQuantity` elements:
 
@@ -1161,6 +1164,8 @@ The examples in #4 are due to the following ordering of the `unitQuantity` eleme
 4.  …
 ```
 
+Note that this uses an ordering of elements _within_ a unit identifier. It is different than an ordering _of_ separate units, such as within a table.
+
 ## Mixed Units
 
 Mixed units, or unit sequences, are units with the same base unit which are listed in sequence.
@@ -1180,12 +1185,15 @@ However, when all of the units would be omitted, then the highest unit is shown
 
 Implementations may offer mechanisms to control the precision of the formatted mixed unit. Examples include, but are not limited to:
 * An implementation could apply the precision of a number formatter to the final unit.
-  However, this mechanisim has a couple of disadvantages, such as matching precision across user preferences. For example, suppose the input amount is 1.5254 and the precision is 2 decimals.
+  However, this approach has a couple of disadvantages, such as matching precision across user preferences. For example, suppose the input amount is 1.5254 and the precision is 2 decimals.
     * Locale A uses decimal degrees and gets 1.53°.
     * Locale B uses degrees, minutes, seconds, and gets 1° 31′ 31.44″
 	* Locale B has an unnecessarily precise result: the equivalent of 1.52540 in precision.
-* An implementation could allow a percentage precision;
-  thus 1612 meters with ±1% precision would be represented by **1 mile** rather than **1 mile 9 feet**.
+* An implementation could match the decimal precision that would be used with just the first unit, such as the following:
+    * Two decimal digits with degrees is 1.53°, representing a range of 1.525° to 1.535°
+    * Only continue adding subunits (or fractions in the final unit) if the current amount is not within that range.
+       * 1° 31′ => 1.516666667, so it is not within that range, and we add another subunit
+       * 1° 31′ 31″ => 1.525277778, so it is within range, and we don't add any fractional units
 
 The default behavior is to round the lowest unit to the nearest integer.
 Thus 1.99959 degree-and-arc-minute-and-arc-second would be (before rounding) **1 degree 59 minutes 58.524 seconds**.