In fact, if KWin keeps issuing a series of brightness writes to PowerDevil's displays, what's the issue with the display interpolating between values until a new one comes in from KWin?
It delays setting the correct brightness value, which changes the animation curve. With kwin!6138 this causes pretty annoying flickering because KWin adjusts other properties according to the brightness value it sets, and that doesn't work if powerdevil doesn't actually set that value.
My guiding principle would be that it's up to each display type whether and how it implements its brightness setter, and the caller should at most provide some declarative context in which the setter is being called (so it can optionally decide to optimize for that).
That only works as long as you limit the whole thing to considering the backlight brightness as a direct setting that the user sets with the slider / brightness keys / power state. That's not what we're doing anymore, KWin needs to know what the display will do and adjust its behavior accordingly - whether to animate or not, and whether it can do things like kwin!6138 or not. As a proxy for that I planned to just only do both with internal panels, and not do it with external display brightness (as they're all DDC/CI anyways), but we could of course plumb that through more properly as well.