Is there a chance the cast could fail?
Otherwise also use a static_cast, given you do not check the result, is faster (or is it a cross-cast?).

I don't think it can fail. decoration() is a QPointer (https://api.kde.org/kdecoration/html/classKDecoration2_1_1DecorationButton.html) do you mean that with cross-cast?

Assumes there is no other custom palette set before we set ours here. Does that assumption hold? Or could KWin & Co do mess with that palette as well?

Looking at the rest of the code, it always tests for decoration() resolving to an existing Decoration pointer.
While I would have expected it might be ensured that decoration always is of type Breeze::Decoration, but Button::create(...) takes a KDecoration2::Decoration, so at least by code in this class this is not ensured.

Now, Button::paint(...) already has half the check ealier, by the

if (!decoration()) return;

But this does not ensure we have a Breeze::Decoration type.

And QPointer only ensures that the pointer is updated if the object is deleted elsewhere. It still can be nullptr, and possibly this is done here as the decoration object is not owned by us, so something might delete it behind the button's back.

So IMHO this logic might need another check by someone who can tell if the right type can be still assumed (which ideally then should be reflected in the API, so it is clear no other type could be present.

I will look into it

KWin doesn't change the palette, it uses to global one to draw the icons for example when you right click on a window titlebar.