I haven't worked on the Extension or Reflection libraries since 2008, primarily because of the difficulty of making it work in a predictable and consistent way across platforms. In general, the tricks involved with getting allocation and deallocation to work correctly across shared library boundaries required a lot of special case code on some platforms, and made it difficult to get the sort of simple API I was hoping for.
As such, I have made no effort since then to keep the library compiling and functioning with new compiler versions, nor with C++0x.
It would be possible to reimplement the Extension and Reflection code in a reasonably simply way with far less verbosity and templates using C++0x additions to the language. If it were not a requirement to make the code work across a variety of platforms and compilers, one could write a small custom version of the code for their own project.
In my current coding, I generally prefer to use either statically compiled binaries, or distinct processes communicating over RPC or IPC, rather than dynamically loading shared libraries. I have yet to find, in my own coding, any place where dynamic loading of shared libraries worked better than either of these two methods. The motivation for using dynamically loaded shared libraries was performance. I have never actually had a project where performance was critical, and I couldn't just compile static binaries.
This is not to say that there aren't use cases for dynamic loading of objects from shared libraries -- just that the complexities in building a cross-platform solution in C++ without a major runtime performance penalty were rather more than I was willing to put time into.
I've removed Boost.Extension from the Wikipedia article on plug-ins, so hopefully fewer of you will waste time attempting to get it to compile on newer compilers.