I have no desire to retain the pre-installed “MS Windows 9x” application-style, nor the Plastik window decorations:
In Plasma 5, the uninstallation icon was disabled, and in Plasma 6, there is no such icon. Unlike Fusion, which I believe is a fallback where Breeze is unavailable, I don’t see the utility in forcing the user to retain these. Consequently, why?
My guess would be that these have been installed via distribution packages, so they are not user removable, unlike those downloaded by the users themselves.
So which ones are there, how and if they can be removed will likely be very dependent on the distributor’s choices.
@Krovikan, I can’t easily OCR a complex bitmap, so is that a pre-installed theme, or one installed from Pling / KGetNewStuff?
@krake, I was very ready to believe you, except that whilst searching for the path to the relevant QStyles / QQuickStyles that I presume that kcm_style enumerates (so that I could enter them into dnf5 provides), I saw an anecdote by @cfeck that these really might be unremovable: [1]
Let me add the information that Fusion and MS Windows 9x are usually compiled into the QtGui library, so they are not installed separately.
…perhaps, this is a discussion I should have with upstream Qt? It’s surprising, if so.
In my screenshot, this decoration was installed from me following the arrow to download:
Same for Dexy-Aurorae, Dexy-Blur-Aurorae, Wings-Blur-Light-Aurorae and Wings-Light-Aurorae.
Regards
Qt is ridiculously configurable at build time and it needs to be because there are so many different usage scenarios.
Having said that I went and looked at the code 
It appears that when building Qt you can decide whether to include Windows 9x and/or Fusion but when you do so they are indeed built-in, not plugins.
I guess most builders will either keep at least one of them available as a fallback or bundle their own style as a fallback.
For a Linux packagers it likely makes sense to keep at least Fusion built in but they could probably use package dependencies to ensure that at least one style is installed.
@Krovikan, in which case, it shouldn’t be relevant, since it’s from KGetNewStuff. Verify that your uninstallation method applies to Plastik (and/or Fusion and Breeze).
Indeed. Fusion was useful during the Qt 5 to 6 transition, and is, I believe, recommended by Qt themselves as a default (although it’s not a very well-designed theme, being oft comprised of bitmaps).
However, I really don’t see why Windows 9.x should be compiled into QtGui, when the package manager [1] provides a significantly more adaptive method of theme management (and the same for Plastik and KGetNewStuff, although the package manager ideally applies here too). Consequently, if no official KDE guidance on this exists, I’d say that it should be created. I don’t mind contributing a sentence about it.
I can’t. The only as installed that I can uninstall is Amy-Dark-Aurorae-6.
All other decorations, included the 2 versions of Dexy* and the 2 versions of Wings*, are uninstallable (and were installed by me from KGetNewStuff the Dexy and Wings). 
Regards
@Krovikan, perhaps, due to the language divide, we misunderstand each other, or I at least misunderstand you. To rephrase, I’m aware that window decorations installed via KGetNewStuff (the arrow) are uninstallable:
What I’m requesting confirmation of is that you’re unable to uninstall those decorations which are pre-installed, of which Plastik is one, in Fedora.
¿Quizás sería mejor hablar español?
For me yes, I am spanish. But no all forum knows the language.
I am in openSUSE TW (is also RPM distro).
I can’t uninstall any of them. Nor Plastik (pre installed), nor Fusion (pre installed), nor Dexy* (installed by me through the menu), nor Wings* (installed by me through the menu). But some strange, I can uninstall (as I put in my screeenshot in above post) the Amy-Dark-Aurorae-6 (installed by me through the menu).
Regards
@Krovikan, thanks! I can’t do so on OSTW, either.
At least we’ve ascertained that there’s a commonality in how openSUSE and Fedora package their Plasma WDs. I’ll ask why Plastik is pre-installed at Fedora and openSUSE’s Discourse instances, when I’ve ascertained where the WDs are stored, so that I can confirm what package they’re provided by (if any, during installation; they might be installed by Plasma afterward, like digikam does):
@Krovikan, I’ve since ascertained that, at least the Plastik WDs, can be removed! The aurorae package, which appears to be merely installed by default on cpe:/o:fedoraproject:fedora:42, [1] provides them.
In this case, I suppose that an FR for having kcm_kwindecoration able to invoke plasma-discover --backends packagekit’s uninstallation functionality (however that’s possible without support for packages without AppStream metadata) [2] would be appropriate. This isn’t a Brainstorm post, though.
To summarise (for the “Solution” plugin):
In kcm_style:
QtGui can be compiled with QStyles / QQuickStyles, which cannot be removed without recompilation.
However, the package manager can also include these as binaries. These can be removed, insofar as they’re not hard dependencies.
In kcm_kwindecoration, the package manager can install entries, as can KGetNewStuff. However, KGetNewStuff doesn’t install anything by default.
A GUI to invoke Discover with these packages prefilled doesn’t exist.
I guess that would be very difficult to do as distributions have very different package structures.
Some might bundle decorations into a single package or bundle decoration and respective widget style, etc., or even bundle them into larger packages
@krake, it should be dynamically discoverable, since PackageKit’s pkcon search file provides a way to dynamically correlate files with packages, across distributions. [1]
Interesting. So I guess it would technically be possible.
However, package dependencies could still be messy and very distribution specific.
@krake, yeah. I presume that there would need to be error handling for when the PackageKit backend (like zypper’s, I think) doesn’t support it.
Not just errors.
Some distributions have “meta packages” which don’t contain anything themselves but pull in all sort of things through dependencies.
For example there could be a package called “plasma-desktop” (or similar) which pulls in the decorations/styles as a dependency.
Uninstalling the decoration/style package would then require to also remove the meta package.
Consider this happening to a less advanced user: they click “remove this decoration” and get a question whether they are OK with removing “Plasma Desktop”.
Depending on the package manager it might be possible to keep the meta package with unfulfilled dependencies, etc. but these options might vary a lot between these systems
@krake, good point! Don’t want a repeat of that LTT malarkey. And that was at the CLI, too, so he had the text before him of what it would do. That couldn’t well be communicated with systemsettings’ current design.
