I strongly suggest that the goal of using CMake with Boost begin with making Boost libraries, whether header-only or built, available to CMake projects. This also means that we have a way of testing whether or not such a solution actually works for any given Boost library. My own preference for testing whether or not such a solution would work or not would be to use our current b2/Boost Build test jamfiles, but if this is too difficult to do we still need some way to test the solution for each library so each library maintainer can see whether or not the solution we choose works for his library.
Are you talking about writing a CMake Config for installed boost? If so I'm strongly in favor of doing so! You'd need some BoostConfig.cmake files with appropriate contents. They are similar to pkgconfig files, so small text files. Those can be (mostly) generated by CMake when it is used to build boost and in the end they replace the FindBoost.cmake currently shipped with CMake (and which the CMake maintainers dislike) Starting from the "other side" would allow some experimentation on how Boost can be consumed by CMake projects and will show many pitfalls early. For example one would need to think about how to deal with the variants (static/dynamic, debug/release[actually simple], static/dynamic runtime, versions installed to same folder, ...) If this is solved, one can go further and implement the actual build system. Note that at this point naming conventions are already established and the current build system can be used to generate these files requiring less effort.