It just so happens that I've been working on a PR to convert bindgen to using the Clang libtooling interface (the C++ libraries for Clang, often distributed as static libraries) rather than the libclang C interface. The libclang interface exposes a rather limited set of information about the C/C++ AST, so bindgen has to work around a lot of missing information. Switching to libtooling would make fixing a bunch of outstanding issues and adding some new features in bindgen significantly simpler. I've already fixed bindgen's layout of C++ classes with virtual bases and started adding support for generation of C++ vtables on top of this conversion. If we can make this happen I think bindgen will be substantially better for it.
However, work on that switchover has stalled a bit due to not having a good solution yet for building bindgen against libtooling on Windows. The official Windows LLVM installer package doesn't include the Clang C++ libraries and only ships the C libclang library, so users currently would need to compile their own build of Clang on Windows to link bindgen against. Most binary distributions on Linux and Mac OS include the libtooling C++ libraries, so switching wouldn't affect most people on UNIXes.
I've been trying to get the libtooling libraries added to the Windows packages, however, one workaround that @emilio thought of was shipping appropriate Clang libraries in the Rust binary distribtions, as is being suggested here. All this to say, if we could make libtooling (instead of or in addition to libclang) an optional toolchain component, I would be super excited.
TL;DR Yes, please! We can make bindgen a lot better if we can just get the Clang C++ libs shipping in the toolchain.