(1) Platform -- detection for what GUI library is being used; native (GTK?, PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or cross-platform (wxWidgets, Qt, etc.) and the platform being used for that cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc.
I don't understand why you even mention the word "platform". C/C++ were born to be (very) portable languages. You would not bring it up with regard to the entity called 'int' right?
Actually, I suspect somebody *did*, when the C language was first being designed and standardized, because the behavior of the 'int' type is dependent on the support of the platform (the hardware, in this case) for integer operations, and the int type had to be defined in a way that was flexible enough to take advantage of that capability on almost any hardware. That's why int doesn't have a specified number of bits- so that it can adapt to the platform. That's one reason C/C++ code isn't as portable as one might like. The same applies to a standard GUI library, but raised to the Nth power. Such a library would have to adapt itself to the GUI capabilities provided by the host platform. This doesn't mean comitting the library to a single platform, but it does mean enabling the library to take advantage of whatever capabilities are present.