POV folks pay attention:
One of the things that has nagged @Mark_Kriegsman and I about FastLED’s scaling math of late (specifically, the math that we use for everything - including the inline brightness/color correction) is that it has a small quirk, in the name of speed.
Many of you folks have run head long into this.
I’m talking about the dreaded scale8(255,255) = 254 ‘issue’. (If this hasn’t ever bothered you, feel free to skip the rest of this, just know it’s been fixed 
This was a side effect of a performance decision made early on - but we’ve put work into being able to fix it (I did up a blog post a bit ago on optimizing this for avr - https://gist.github.com/focalintent/0d2de5159f6f9d47fcec).
The big trick was making sure that everything else in the library was in line. This includes the asm code for 3-wire led chips on AVR and ARM M0 chips. This also includes various other places in the library that may have tried to account for this (or exploited this).
In a fit of cascading changes and choices to not sleep, last night @Mark_Kriegsman and I finished getting this fix across the entirety of the library, and it’s now been pushed to the master branch.
What does this mean for you? Well - now, if you’re running with setBrightness(255) (and no color correction/temperature defined), then the bits that are in your CRGB array are exactly what’s getting written out. (For POV folks, this will be great - no more extra gap for solid, full bright colors. For POV folks using WS2812’s, first off - WHY?!? Secondly, you’re still going to see gaps, because the WS2812 does one dark cycle between every PWM cycle, even at all on).
What else does it mean for you? This will cut back on cascading errors across multiple scale8 calls. You’ll see smoother ramps in lower HSV values.
The rumors about cats and dogs sleeping together are just that, rumors, and even if true, no one can prove that has anything to do with us fixing scale8.
If you need to turn it off - you can edit the file fastled_config - and change the value for FASTLED_SCALE8_FIXED to 0.
(And for the folks playing along at home, this was the last major bug/issue that I wanted to get fixed before turning my attention to RGBW/RGB16)