I don't think it's necessary for libbpf to expose all these new APIs.
The format of CO-RE relocations and .BTF.ext is open and fixed. You
don't really need to simulate full CO-RE relocation logic to figure
out which types are necessary. Just go over all .BTF.ext records for
CO-RE relocations, parse spec (simple format as well) and see which
fields are accessed.

How do you suggest to match the types for the target BTF without
simulating the CO-RE relocation? Are you suggesting to match them only
by name? We want to generate the minimal BTF that is needed by a given
object. Consider that we could generate these files for thousands of
kernels, size is very important for us. For this reason we chose to
simulate the relocation generating only the types (and members) that
are really needed.

Either way, this is not libbpf's problem to solve. It's a tooling problem.

I agree. When I started working on this I tried to implement it
without using the libbpf relocation logic, but very soon I realized I
was  reimplementing the same logic. Another possibility we have
considered is to expose this relocation logic in the libbpf API,
however I fear it's too complicated and invasive too...