How to make the CTags plugin default disabled for only KDevelop, but not Kate?

[Friedrich W. H. Kossebau]

Hi,

with the Kate Addons plugin CTags having now in its metadata
    ServiceTypes=KTextEditor/Plugin,KDevelop/Plugin
this results in this plugin also being loaded by default in KDevelop. For 
everyone, until they explicitly remove it from the enabled plugins.

Which kind of ruins at least the first time user experience for a user with 
KDevelop on a system which also has Kate installed (which I would expect to 
be lots, if not majority).
Because KDevelop in theory does not need this plugin due to its own (great) 
code symbol engine. And making this plugin available also for KDevelop was 
only meant to be for a niche of users (or only one?) where KDevelop's own 
engine can not be used for reasons.

See https://phabricator.kde.org/D16779 for some background.

So, this plugin should by default be disabled. But only for KDevelop. I 
assume at least Kate wants to have it on by default.

I am wondering about the best approach.

There is the KPlugin metadata entry
    "X-KDE-PluginInfo-EnabledByDefault" (desktop file)
resp.
    "{ "KPlugin": {  "EnabledByDefault": true/false } }" (embedded JSON) to 
control this usually. But this entry would be read both by Kate & KDevelop 
(and other potential KTE plugin users).

The ctags plugin could be caught hard-coded in KDevelop code. IMHO not nice 
(only okay as temporary fix for 5.3.3 release)

We could add invent a new metadata key "X-KDevelop-PluginInfo-
EnabledByDefault", have the CTags plugin set that to "false" and extend 
KDevelop's plugin code to also check that.

Opinions? Better ideas?

Cheers
Friedrich

PS: yes, there is also the duplicated context menu issue in KDevelop where 
this plugin triggers the bug elsewhere, right now wrapping my mind around 
this again to see how the latest version of D16882 might be at minimum a 
current protection, if not the only goable solution. But separate issue.