I looked into it a bit more, and it turns out it's a result of OKLCH easily producing colors out of gamut, and then choosing to sacrifice hue accuracy for better saturation accuracy.
That's a fundamental design flaw if you ask me. Changing hue is completely unacceptable in my book.
> Since different hues have a different perceived brightness, another way you can change the brightness of a color is by rotating its hue.
> To make a color lighter, rotate the hue towards the nearest bright hue — 60°, 180°, or 300°.
> To make a color darker, rotate the hue towards the nearest dark hue — 0°, 120°, or 240°.
> This can be really useful when trying to create a palette for a light color like yellow. By gradually rotating the hue towards more of an orange as you decrease the lightness, the darker shades will feel warm and rich instead of dull and brown
You could argue whether this is "perceptual uniformity" or something else, but the fact is that to create a realistically useful colour palette with a bunch of shades, you definitely cannot simply use HSL, keep the hue constant, adjust S/L. It's not that easy (and OKLCH doesn't make it that easy either).
There is absolutely no perceptual hue shift in the HSL/HSV models depending on saturation and lightness/value, or when they get translated into sRGB. That's the entire point of HSL/HSV, to isolate hue and hold it constant.
HSL/HSV are not perceptually uniform in terms of brightness when hue is changed, or even brightness linearly. But hue is hue. Perceived hue does not change based on brightness or saturation.
