This was my thought as well. In fact, I'm going to switch all our BOOST_CLASS_EXPORT(T) macros to BOOST_CLASS_EXPORT_GUID(T, "[T's canonical name]") macros, and leave a giant note for others to do the same ("Here there be dragons", etc.). In light of this problem, I would say that while use of BOOST_CLASS_EXPORT() is convenient, it is ultimately a maintenance burden.
In my opinion the convenience of BOOST_CLASS_EXPORT is offset by the problem Zach is facing, as well as by the physical coupling it introduces between user classes and boost::serialization. Because serialize/load/save are function templates, and because all serialize/load/save calls made from inside another serialize/load/save function template depend on a template parameter (the Archive type), in principle the serialization of a given class foo can be defined in foo.hpp without including any boost serialization headers, however this is not possible if BOOST_CLASS_EXPORT is used, because its purpose is to trigger the registration automatically just because foo.hpp is #included. I would suggest separating all registration in a single compilation unit called explicitly by the main initialization code (having everything in one place makes it much easier to keep track of the IDs for each class.) That compilation unit would include the headers of all classes that need to be serialized, as well as the registration facilities of boost serialization, and register each combination of class and archive that the program uses (each dynamically linked library would need its own similar initialization as well.) Emil Dotchevski