2) What do we do about common_type?
This is still not addressed, right?
Can you say what the current state of the rewrite is, the intention of how it will be used (ie, replace existing vs maintained in parallel), and blockers to reaching that point?
I've been suffering from sudden laptop failure, which is why I've been silent on this - I'll post more when I'm up and running again - but the current version of the branch should have a common_factor which only has dependencies outside of Boost.Config for broken/obsolete compilers (please note: I haven't fully tested/checked this, and won't until my new laptop arrives sometime next week). In such a case I think it would be acceptable to manually mark up that header with some "don't track dependencies" directive and require users to manually add Boost.Typeof to their list of required modules if they're using an old compiler. Note that we need some kind of markup facility to deal with optional dependencies anyway - to avoid the "everything depends on Serialization" issue. So maybe something like: /* BPM nodepend BPM start_message Note: If you're using boost::common_type with a compiler that supports neither the decltype nor typeof keywords, then you will need to manually add the "typeof" library to your download list. BPM end_message */ Other than that, I've nearly finished testing the new version and IMO it looks good enough to simply replace the old version - but again more later. John.