In case a C++ plugin can have a KPackage associated with it, the metadata is both contained as embedded json metadata and a metadata.json file in the package. This means that at runtime both are loaded in memory. In case of some KCMs there are even separate metadata, which duplicates some user-visible strings.

The alternative would be to allow C++ plugins to set the metadata for the associated KPackage. This will make the embedded json metadata the single source of truth for the metadata.
Additional properties (like X-Plasma-API or X-Plasma-MainScript) will then have to be moved to the embedded metadata. But considering that those we only two key-value pairs it should not be controversial.

With https://invent.kde.org/plasma-mobile/plasma-settings/-/merge_requests/96 the KCMs loading prefers the embedded json metadata, systemsettings does this too.

A perquisite for this is https://invent.kde.org/frameworks/kpackage/-/merge_requests/28 which makes sure the KPluginmetaData object is properly copied when one wants to copy the KPackage::Package class.

Because of https://phabricator.kde.org/T14517#265603 I want to avoid a third duplication of the translated name & comment, especially if it is not strictly needed.

In KF6 we should always set the metadata for the packages. This way we do not need to check if we have a metadata file available. In case the plugin still has one (maybe just to make kpackagetool happy) we do not waste resources loading it. KPackages do not belong to a C++ plugin we would of course be reading the metadata as we do now.

For the Applets/Containments/Dataengines the same issues applies, however in the opposite direction: Here we use KPackage to query the plugins and load the C++ parts on-demand. Here it might make sense to allow empty metadata when querying the plugins. Similar to how we allow it for KCM loading in the KPluginSelector using the X-KDE-ConfigModule property.