On my system, the following parts need to be adjusted:

akregatorpart.so calligraplanworkpart.so fsviewpart.so kaddressbookpart.so kfontviewpart.so kmailpart.so konsolepart.so libcantorpart.so notepadpart.so
arkpart.so dolphinpart.so gvpart.so kdesvnpart.so kigpart.so kmplotpart.so korganizerpart.so libmarble_part.so zanshin_part.so

Moving the parts into the subdir also needs to make sure no-one is using KPluginLoader(const QString &plugin, QObject *parent) to load the part, as that method will not look into that subdir to match the passed plugin binary name.

D18881 gives an example what was needed to do with Krusader when I moved the oktetapart around.

And the ones already in "kf5/parts" IIRC were all (besides the katepart one, which inspired me) moved to that location by me. Only once I got to Okular & Co. I realized this might not be possible without breaking things for existing code going directly for the plugin binary name, and fixed things with Krusader at Krusader side only as aftermath.

My take-away at the time was that the complete move of all KParts needs to wait until KF6.

The kdepim parts are not general purpose parts associated with a mimetype, they are found via the desktop file for kontact plugins (which are themselves currently found via a Kontact/Plugin servicetype).

So they should move elsewhere, e.g. kf5/kontactparts for the KParts, and kf5/kontactplugins/ for the "Kontact/Plugin" plugins.
They are located by kontact using KServiceTypeTrader and I'm pretty sure nothing outside kontact uses them, so they could move without waiting for KF6.

$ ktraderclient5 --servicetype Kontact/Plugin | grep 'X-KDE-KontactPartLibraryName' | sort | uniq
X-KDE-KontactPartLibraryName : 'akregatorpart'
X-KDE-KontactPartLibraryName : 'kaddressbookpart'
X-KDE-KontactPartLibraryName : 'kmailpart'
X-KDE-KontactPartLibraryName : 'korganizerpart'
X-KDE-KontactPartLibraryName : 'zanshin_part'

I just realized that just moving the install dir isn't enough for parts to be loadable with KPluginLoader/KPluginMetaData, they also need full JSON metadata built into the plugin.

$ for f in *.so ; do echo -n "$f:" ; if qtplugininfo --full-json $PWD/$f | grep -qw KPlugin; then echo OK ; else echo ERROR; fi ; done
kmanpart.so:ERROR
okularpart.so:ERROR (my patch D26163 was incomplete, fixed now)
gvpart.so:ERROR (my patch D26349 was incomplete, fixed now)
(same for kmultipart.so, and khtmladaptorpart.so+kjavaappletviewer.so have no json at all, but those are all deprecated KHTML stuff)

oktetapart and webenginepart are ok ;)

In the KF6 sprint today it was said that I took care of kdepim, but that's not the case. That was for kontact plugins (e.g. D28608), not for the KParts.

The kdepim parts are loaded by name from KontactInterface::Core::createPart, which does e.g. KPluginLoader("kmailpart"), which resolves to PREFIX/lib64/plugins/kmailpart.so. I think that means it's all fine, they can keep living there. Nothing needs to iterate over kdepim parts, so no need to move them to a subdir.

kdesvn: https://invent.kde.org/sdk/kdesvn/-/merge_requests/1
arkpart: https://invent.kde.org/utilities/ark/-/merge_requests/40
kfontviewpart: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/771
kigpart.so: https://invent.kde.org/education/kig/-/merge_requests/3
kmplotpart.so: https://invent.kde.org/education/kmplot/-/merge_requests/3
libcantorpart.so: https://invent.kde.org/education/cantor/-/merge_requests/30

Skipping:
libmarble_part.so: all the desktop files are commented out because the part is broken. Someone else's problem.
calligraplanworkpart.so: discarded, see https://invent.kde.org/office/calligraplan/-/merge_requests/1

Those have to wait for KF6:
konsolepart.so (many apps load it by name)
okularpart.so (D26163 ready but would break generators that are not part of okular's repository)

konsolepart.so (many apps load it by name)

Moved as part of the KF6 port

okularpart.so

To be done when porting to KF6

In T12340#253307, @dfaure wrote:

The kdepim parts are loaded by name from KontactInterface::Core::createPart, which does e.g. KPluginLoader("kmailpart"), which resolves to PREFIX/lib64/plugins/kmailpart.so. I think that means it's all fine, they can keep living there. Nothing needs to iterate over kdepim parts, so no need to move them to a subdir.

IMO we should still have them somewhere else than the top-level plugins folder, if only for cosmetic reasons