IMHO, the real solution is to avoid exposing opaque types from library C in the interface of library B. Obviously, some libraries do this anyway, so your critic

IMHO, the real solution is to avoid exposing opaque types from library C in the interface of library B. Obviously, some libraries do this anyway, so your criticism is valid. Library C's headers would likely need some #define to link to the old functions and types for compatibility. But transparent aliases are still very effective in the case of shallow dynamic-library dependency graphs (e.g., most open-source projects), even if, as you note, they aren't a panacea. (I'm not even sure there is one: there'll always be a Y2038 bug or TLS deprecation or whatever that library C needs to make a breaking change to fix.)