Which problem would this solve for them?

It would standardize something they've done with a home-brewed tool for decades. They have a library called "reflex" [1] which adds some reflection, and which was (re)written by cannibalizing a lot of llvm code. They actually use the reflection to serialize a lot of the LHC data.

It's kind of neat that it works. It's also can be a bit fidgety: the cannibalized code can cause some issues (which, e.g. prevented C++11 adoption for a while in some experiments), and now CERN depends on bits of an old C++ compiler to read their data. Some may question the wisdom of making a multi-billion dollar dataset depend on the internals of a C++ compiler, but for sure having a standard is better than the ad-hoc solution they rely on now.

[1]: https://indico.cern.ch/event/408139/contributions/979831/att...

The library that you refer is not in use for a long time already. The document you pointed out is from 2006 (you can check the creation date).

Since then, a lot has changed, and now it is all based on cling ( https://root.cern/cling/ ), that originates from clang and llvm. cling is responsible generates the serialization / reflection of the classes needed within the ROOT framework.

Good catch: I'm confusing reflex and the cling code that came later. All the issues I mentioned are still there in (or caused by) cling though. Either way standardization in reflection would help.

Two language problem, kind of well known issue in engineering tradeoffs.

As an example, most of the big js/ts ecosystem expansion to the server (RSC/Next/RR7/Expo/...) over the last few years is driven by the wish to have everything under one roof and one language.

People just don't want to maintain two completely different stacks (one on the server, one on the client).