lipchev

Hey guys, I've just had a look at this - and it appears that the only tests that are failing are from the `UnitsNet.Serialization.JsonNet.CompatibilityTests` project- which IMO should have been...

It's incorrect in referencing the converter via the nuget, while the UnitsNet core is referenced using a project reference. Had the reference to the converter been via direct reference it...

Although it might be argued that the tests actually did their intended purpose- if that was to test the latest UnitsNet version against UnitsNet.Serialization.JsonNet v4.4.0 - it was correct in...

Would the explicit definition of a "Scale" help? I see that [the OM ontology](https://github.com/HajoRijgersberg/OM) has that addition to their quantities. To quote the paper: > Each quantity can have more...

[One](https://github.com/angularsen/UnitsNet/pull/911#pullrequestreview-627574589) possible modification to the JSON converter schema. I would ever go further and suggest we default to something like `{"1", "kg", "Mass"}` (there is no ambiguity with the unit...

Hey guys, ignore this if you're busy- just pinging out to ask if there is something I should do to move this forward.

I gave it some more thought tonight- and I no longer think this is a good idea. Not that it doesn't do what it was supposed to (`q == q.ToUnit(X)`)...

The problem is that the "safest" option in this case {unit, value} would be quite a breaking change. Anyone who has ever used something like x == Mass.Zero or default(Mass)...

So, I've reverted the `Equals` method (same as before) and made the `GetHashCode()` return only the `QuantityType`'s hash-code- as such it would match the contract requirements. However, I'm pretty sure...

Initially I went with a dictionary (as proposed in #651) but being stunned by the lack of improvement in performance compared with the test in #708 I dropped it in...