I think the important question here is what mode do we want.
One mode is where you have a feature test as a .cpp file which tries to use "important" functions from a library, and then declare a Boost.Build metatarget that builds that .cpp and links to a library. In this case, if you modify the .cpp, the regular dependency checking will rebuild the test. Also, the test will be repeated if the system headers for the library change -- a particularly nifty example is including "whatever/version.hpp" and making some decisions based on version. Some changes to the way libraries are linked will allow the test to be rebuilt when a system library itself is modified.
Another mode is where configure checks tries to compile or link something, and caches the result. One can remove the cache and run all checks again, but otherwise the system assumes nothing changes.
I, personally, is not very happy with the second mode as implemented in cmake. However, it might be that the best mode depends on the nature of the test, and we need to support both. Comments?
I'm not happy with the second mode either - if something in the source changes then the test should definitely be rebuilt - most users will presumably only build the thing once anyway during an install so it won't make any difference to them? John.