@ericsagnes, thanks for your PR! By analyzing the history of the files in this pull request, we identified @cdepillabout and @abbradar to be potential reviewers.

I tested this pr and can confirm this solves #23395

Does fcitx-qt5 provide any shared objects besides a plugin? If not, it should be moved out of libsForQt5 into the top level because it only needs to be built with the latest Qt version. (Qt plugin ABIs are backward-compatible.)

@ttuegel Thanks for looking into this!

Does fcitx-qt5 provide any shared objects besides a plugin?

As far as I know it is only a plugin.
But, I remember there was an incompatibility with Qt 5.5 applications as pointed in #15569 (comment) that motivated the move of fcitx-qt5 in qt5LibsFun.

If not, it should be moved out of libsForQt5 into the top level because it only needs to be built with the latest Qt version.

I have not followed the recent changes of the Qt structure in nixpkgs, but will that ensure that #15569 like incompatibilities will not happen anymore?

But, I remember there was an incompatibility with Qt 5.5 applications as pointed in #15569 (comment) that motivated the move of fcitx-qt5 in qt5LibsFun.

Qt plugins are backward ABI-compatible, i.e. a plugin built with Qt 5.8 will work with any version of Qt 5 <= 5.8. The only reason this would fail is if the plugin uses private Qt headers, and I recall that is the case here. Putting it in libsForQt5 doesn't really solve the problem because a user can only have one version installed at a time: either their Qt 5.5 applications work, or their Qt 5.6 applications, but never both at the same time. The only real solution here is to file a bug upstream: the package is broken by design. Until there is a better resolution, though, I think you're right to keep it in libsForQt5.

Thanks for merging and the explanations.
I will look at the upstream package and try to submit a fix.