If we agree that libbitcoinconsensus should not depend on chain.o, we need some other dependency as a requirement.
This same thing could be done with a "final" almost-C-ready API instead of a CPP abstract class (and that was my initial idea), but that would be more disruptive and harder to review.

Not introducing a non-storage interface for CBlockIndex is blocking the following things:

• Decouple pow.o from chain.o and move it to the consensus package
• This will allow us to decouple consensus/consensus.cpp from chain.o right away (once MOVEONLY: Move consensus functions out of main #7310 or similar is merged)
• This will allow new consensus code (for example, an implementation of bip9) to avoid depending on CBlockIndex. This will also allow to s/CBlockIndex/CBlockIndexView in small encapsulation commits while minimizing disruption.