Hey!
LESS version 3.8.1 introduced outputting HSL color values as authored instead of their HEX counterparts (e.g. hsl(0, 0%, 76%) outputs hsl(0, 0%, 76%) instead of #c2c2c2 now), which is a really cool feature. However, using HSL colors with variable interpolation sometimes (depending on the color parameters) outputs the color slightly imprecisely (and very ugly):

(v3.8.1+)

@color1: hsl(56, 8%, 14%);
@color2: hsl(0, 8%, 1%);
.color-element {
  color: ~"@{color1}";
  color: ~"@{color2}";
}

expected result:

.color-element {
  color: hsl(56, 8%, 14%);
  color: hsl(0, 8%, 1%);
}

actual result:

.color-element {
  color: hsl(55.99999999999997, 8.00000000000001%, 14.000000000000002%);
  color: hsl(8.000000000000004%, 2%);
}

This happens with and without the tilde, obviously.
I'm using two different colors here to demonstrate that not every value is outputted like this, e.g. hsl(0, 8%, 17%) is completely fine - notice here that the values are dependent of the others (with 17% lightness, the 8% saturation is suddenly fine).

However, not using variable interpolation works as expected:

@static-color: hsl(56, 8%, 14%);
.color-static {
  color: @static-color;
}

result:

.color-static {
  color: hsl(56, 8%, 14%);
}

I have also tried with HSV and RGB, but those ones are still being converted into their HEX counterparts, which is why I'm not sure whether the sudden HSL preservation is a feature.
This is tested using lessc on Windows 10.
A reason I can think of is that it's maybe caused by converting the HSL values into HEX and then back into HSL again, but what do I know.
I would expand the example a bit but the less playground is apparently not yet updated to 3.8.1+.
Hallo89