The problem is services and non-ABI/non-library APIs. The way I suspect that this is set up is that there is precisely one KDE widget displayer service at any g

The problem is services and non-ABI/non-library APIs. The way I suspect that this is set up is that there is precisely one KDE widget displayer service at any given time, running as part of the desktop environment and presenting an IPC interface that widgets talk to to get themselves added to the widget display area that the window manager maintains. You can link statically to the KDE widget client libraries all you want; if the KDE widget server decides to change the language it speaks, your widgets are hosed unless you included a not-a-widget mode that makes it a normal window. Seeing as how widgets tend to have special build systems (or, worse, the widget server is actually an interpreter for a declaration-heavy widget definition language that's not strictly plaintext), I don't think I've ever seen a widget with a non-widget mode supported. "Breaking userspace" probably is a misnomer, if only because userspace has a precise technical definition. This is more like changing an interpreted language without maintaining backwards compatibility (python3, anybody?) or changing a json API.