Notes from the KF6 weekly:

It seems KServiceTypeTrader may be still useful.
Related XDG discussion on standard dbus interface to open a terminal and run
commands. This brings the issue on how to select the implementation. The
proposed solution (for now called "intents") looks similar to the idea of
service types.
This will bring something akin to KServiceTypeTraders.
We may just still deprecate it and port it to an intent, which may be
KDE-specific, but still.

I found another use-case for KServiceTypeTrader :) The "Browser Identification" KCM uses KServiceTypeTrader to query a bunch of desktop files that provide user agent suggestions. No binary plugins involved so KPluginLoader does not work.

Before we bring back KServiceTypeTrader from the grave I'd propose to remove the KCM instead since it's usefulness is questionable (see T13853)

Sth. intersting I wanted to share: The KIO "Web Search Keywords" (X-KDE-ServiceTypes=SearchProvider) do not use the KServiceTypeTrader API, but QStandardPaths instead and to get the entries from kservices5/searchproviders/. Similar to the namespaces in KPluginLoader. In this case the SearchProviderRegistry (which contains the described logic) is a member variable of the KURISearchFilterEngine singleton.

Could that be a solution for the KonqPopupMenu/Plugin service type? This way we would keep the desktop files working and currently the vast majority of these services gets already installed into the ServiceMenus subfolder.

Obviously search providers used to use KServiceTypeTrader too, but indeed I ported away from that in commit 6246cc48067845208cf5acd8b798abd68349cf18 (D9213)

You're right, the same could be done for other things which are not C++ plugins.

Obviously keeping KServiceTypeTrader is a valid alternative :)
I only wanted to deprecate it because all plugin-loading needs were otherwise covered, forgetting that it's not only used to load plugins.

Obviously keeping KServiceTypeTrader is a valid alternative :)

Yep, but keeping it around for just one usecase which can be relatively easily ported away from seems a bit lazy :D

See https://invent.kde.org/frameworks/kio/-/merge_requests/469

https://invent.kde.org/frameworks/kservice/-/merge_requests/71