On Xorg with Window Maker and no (desktop) compositor running, my own toolkit (example app[0]) resizes instantly.
On Xorg with KDE5 (not sure which exactly version, whatever openSUSE has) and a (desktop) compositor enabled, same toolkit also resizes without gaps (though there is a small delay, probably due to the compositor, i didn't try without it). Same with native apps.
On Wayland/KDE5 the same toolkit resizes without gaps but there is a visible "lag" for the titlebar to be updated that didn't exist with Xorg/KDE5. Since the toolkit only supports X11 i'm not sure if it is due to XWayland or KDE5 though.
TBH in none of the above configurations that'd be something i'd notice unless i was looking for it - or it was very laggy. Even on Wayland, it is something i noticed because i was resizing the window constantly back and forth to see if there is any lag.
However i didn't link to it intentionally since this site contains a three year old code dump and my current version has a lot of things changed in an incompatible way, so i wouldn't like people using it just yet. I still need to do a bunch of other changes to the API as well as fix some stuff and rethink how some other things work that can be hard to change later if i decide to make a proper release that people can depend on (e.g. i'd like to change how fonts work to allow for arbitrary font styles). I don't have much time for it right now though, but perhaps in a few months i'll be able to allocate some time for it.
I don’t know, if I resize the window I do want the border to reflect the changes even if the app froze, and drawing a black rectangle with a frame and optionally drawing the ready frame made by the app onto it doesn’t sound too hard to me.
Most of the time, though, you run applications that aren't frozen. Sure, having resizing do something in that case is useful, but you don't want those black bars to appear for the fraction of time between moving your mouse & the application redrawing, for every single frame of window resizing where the app didn't redraw in time (text reflowing, graphics initialization & other re-computation can often push resizing frame times above the 16ms of 60fps).
(X11 and its server-side decorations appear to be able to handle this as-is - decoration redrawing is delayed until either the application redraws, or some timeout (iirc around a second or two?), at which point you get the ugly black bars)
There could be the same problem outside of a window given that most windows are rendered by separate processes. Unless there is a compositor, which I think there is? And can that problem you mention not be avoided using a compositor?
So make the compositor use the size of the buffer the window supplied when rendering the decorations (or at least allow the old size for a frame or so). Next problem.
Not taking sides, but why do you need to synchronize two processes when one should only draw a frame and the other should only draw the contents?