Oh come on …you didn’t tell us what you used second time. 
There’s no cheating, there’s just ambiguous notation and unexpected results.
Anyway, easy enough to repeat the exercise. OH2-with-old-UoM-library still differs from your K results.
var t = 20|°C
var t2 = 68|°F
var t8 = t2 * t / t2 // result 20 °C
var t9 = t2 * t.toUnit(t2.getUnit) / t2 // result 68.00 °F
var t10 = t2.toUnit(t.getUnit) * t / t2.toUnit(t.getUnit) // result 20 °C
var t11 = t2.toUnit(t.getUnit) * t / t2 // result 5.882352941176470588235294117647059 °C²/°F
t11 is 
This can be duplicated with constants, for better clarity
var t8 = 68|°F * 20|°C / 68|°F // result 20 °C
var t9 = 68|°F * 68|°F / 68|°F // result 68.00 °F
var t10 = 20|°C * 20|°C / 20|°C // result 20 °C
var t11 = 20|°C * 20|°C / 68|°F // result 5.882352941176470588235294117647059 °C²/°F
Unsurprisingly, t9 and t10 confirm that sticking to one unit “works”.
Is t8 “working” a mystery, then?
I’ll make the assumption that auto-conversion for mixed units is not applied in the divide case (in OH2).
We can test that -
var divpart = 20|°C / 68|°F // result 0.2941176470588235294117647058823529 °C/°F
Yep, it’s just done maths on the numeric parts and made up a unit.
Hmm, curious now …
var divsame = 68|°F / 68|°F // result 1
Aha - at some point in the processing the framework is smart enough to realize that °F/°F is a null unit and discard it.
While °C/°F is not null and is retained.
Here’s the difference we’ve been looking for I reckon.
What about multiply?
var multpart = 20|°C * 68|°F // result 1360 °C·°F
var square = 20|°C * 20|°C // result 400 °C²
Just as daft units, but the point is that we will always get a unit of some kind.
But now we can see what’s going on, if we fill partial results.
// we can sneak weird units past the validator as a string
var t8p = 68|°F * 0.2941176470588235294117647058823529 | "°C/°F" // result 20.00000000000000000000000000000000 °C
var t11p = 20|°C * 0.2941176470588235294117647058823529 | "°C/°F" // result 5.882352941176470588235294117647058 °C²/°F
So the t8p result is “good”. It’s not identical to the “full” t8 calculation, with all those trailing zeros; perhaps just differences in number type handling when parsed.
And the t11p result can be understood. It’s just done simple maths with the numerics, no conversions, same as t8p.
But t8p units would be °F * °C/°F - framework is smart enough to cancel °°F/°F leaving just °C.
t11p units would be °C * °C/°F - no cancelling can be done, leaving °C²/°F
In summary, all mathematically correct, but probably not useful. 5.88°C²/°F is a “correct” answer but not in units we can use.
Maybe this is why UoM library has been updated.
OH2 users can manage all this in real life by following the golden rule “use the same units throughout”
That’s good info.
Maybe 3.1 UoM has a new policy of sorting out conflicting units in some ‘base’ unit, which would reasonably be K. Note that t/t2 has ‘unit/unit’ dimension if they are expressed in the same units, so t * t/t2 represents a conflict between t with unit and divide with unit/unit.
But your K results suggest it is making a right mess of this policy here.
