From personal experience, I can attest that maintaining compiler infrastructure that builds on top of LLVM is hard over the long term. You try to compile something from a year ago with newest LLVM and find that it no longer works. The upstream LLVM developers make breaking API changes and it is the responsibility of downstream clients to fix their code accordingly.
In this essay, we make a broader argument: there are opportunities in analyzing changes to software components and either certifying compatibility or detecting breaking changes. Furthermore, many programming languages techniques (formal verification through testing and of course programming language design) can contribute to the important problem of reasoning about upgrades. We survey the role of contracts and discuss how to best determine the exposed API surface of a component.