There is a lot at stake here. The entire ImageJ2 ecosystem of plugins is built around this mechanism. If you find any better existing solution, let’s discuss whether it could be adopted under the hood to improve the entire software stack. Or if the SciJava plugin mechanism is the “least bad” but has certain deficiencies, let’s discuss how to address those deficiencies.
I understand that it is tempting to simply cherry-pick all the most technically suited tools for each individual project, but there are serious social consequences to the inconsistency that doing so creates. We need to consider not just the in-the-moment technical issues, but what developers new to the ecosystem see when they start exploring the available tools. ImgLib2 and Java in general already have a reputation for being “too complex”, especially compared to the Python numpy/scipy/scikit-image stack. As insiders, you and I know the added value that ImgLib2, BDV, etc., offer which justifies that complexity. But most developers will not have such insight, and seeing e.g. multiple dependency injection frameworks in use across different components will certainly (and rightfully so, IMHO) add to that perception.
Each JAR file contains its own plugin metadata. These get “merged” only insofar as the indexer calls ClassLoader#getResources and iterates on all results over the whole classpath.
The only time the JSON files get merged explicitly is when creating an uber-JAR. SciJava Common provides an AnnotationCombiner class that can be used to aggregate all the JSON files into one. See also this issue for some relevant discussion.