It appears that includes the native when Boost.config says it's able.

So if one were writing a portable library that uses boost (or bug-fixing an existing boost component), would including be the way to bring it in, or should one look at BOOST_HAS_TR1_UNORDERED_SET and make a decision that way?

There's no mechanism analogous to BOOST_HAS_HASH / BOOST_HASH_<X>_HEADER that has to be navigated, right?

No, so either include boost/tr1/unordered_*.hpp if you want to use the tr1:: versions (native when available), or else include the boost unordered containers directly if you want to use the boost:: versions. HTH, John.