i can only invite those people who experience these warnings to contribute patches to silence them: if warning-free headers are important for your project, it is best to test new boost versions early (maybe even checkouts of the develop branch) and submit pull requests to the specific libraries before they are released ...
Without a general consensus on warning handling policy, this would become a sysiphus job. Let's say I fix the warnings which currently represent problems in my project. During the development of the next release, other people commit new code with new warnings, or may even change the fixes to emit new warnings. I think there needs be general policy that code should not introduce new warnings, and that changed code is warning free. At my job, we have a similar problem with a legacy system that contains thousands of warnings. We use SonarQube to monitor the warnings, and to enforce that changes are warnings-free. Cheers, Jens