So basically if someone has an older lzma they are limited to boost 1.70.0 or earlier. That's perhaps reasonable as long as it is documented, but it hasn't been the typical way I have seen things added to existing code. Well, my second question was if you are confident that 1.70 does actually work with liblzma versions older than 5.1.1? If this isn't tested, it is not supported and if it is not supported it imho makes little sense to complicate the source code to achieve potential compatibility with (what I assume to be) a very, very small number of setups.
I will be testing, with and without my additions, with every numbered version of liblzma before making my pull request. So I'll be able to answer that soon. But that doesn't deal with your real concern: that testing will not be automated and ongoing, and it could mysteriously break in the future. My production systems are RHEL 6. They have a 4.x version of liblzma installed by the package manager, which is incompatible with the changes I am making. I get that RHEL 6 is old, but some industries have to deal with that sort of thing.
However, as long as the interface is untouched by this macro I guess it would be fine.
The design I have right now would leave the interface the same between the macro on and the macro off. I.e. both would have a new "threads" argument and member. The macro would be used only in the cpp file. Working code would work in all cases. Requests for different numbers of threads would just be ignored if it isn't supported. The deeper questions here are above my pay grade. I will bend to the whims of those with more experience maintaining boost.