Currently there is a dependency on Boost headers being present when building a Qpid client application. I believe that Qpid client programmers should not have to be exposed to Boost just for building Qpid applications. It's a Bad Idea to impose a requirement such as this on all users - Boost is a supporting artifact of the implementation and shouldn't be a requirement for users.
More pointedly, it could cause version skew on Windows installed kits. Unlike on RHEL, Windows doesn't offer Boost packages as part of the vendor-supplied OS kit. So, Windows users needing Boost must get their kit somewhere else. This makes it impossible to predict what version of Boost will (or won't) be on a user's system. To take care of this, the Windows installable kit is currently including the needed Boost DLLs that the kit is built against within the install. This removes the need to have Boost installed by the user prior to installing/using Qpid and isolates Qpid's binaries from whatever Boost version is present if there is one. This is a Good Thing except that when trying to build a client app (such as the Qpid examples) Boost ends up getting pulled in from the client API at build time. This is bad because the user now needs to go install Boost. If it's not the same version that the installed kit was built against, there's a chance that object sizes, methods, etc. will differ between what Qpid was built with and what the user installed.
The case that brought this up immediately is that qpid/SessionId.h derives from boost::totally_ordered1<SessionId>. Since qpid/client/Session_Base_0_10.h defines a method which returns a SessionId by value, it needs to pull in SessionId.h which yields a compile error if Boost is not available.