It has struck me over the last couple of days that, despite the "all at once builder" the D tools are front end tools, and that defining a library builder is the job of a linker tool, not the job of a frontend tool. This pull request therefore removes the optional definition of a static library builder. This came to light due to lack of symmetry: there is no shared library builder definition, and yet building shared libraries works entirely as expected. None of the C, C++, Fortran frontend tools define a library builder, so why should the D frontend tools.
This change makes no difference to the tests, they behave the same with or without the lines.
It seems that the link tool does not provide StaticLibrary builder, but only SharedLibrary. Since D has to be able to statically link as well as dynamically link in all build situations, having StaticLibrary is essential. More research happening. But for now this should not be merged.
I guess in the short term the issue is whether the D compiler tools should put StaticLibrary into the environment, when none of the other compiler tools do (as far as I know), at the penalty of having to use the ar tool. The D compiler tools do not put SharedLibrary into the environment, requiring use of link, so are inconsistent on this. I have an inkling of how history has led us to this point, but I don't like this sort of inconsistency, and would prefer to remove the StaticLibrary builder introduction in the D tools.
However, given the data I now have, I have a suspicion someone very soon now is about to say "this is a breaking change, isn't it". And yes, given the data, it is.
I am not sure how long to leave it, but no-one has responded to my email, not even people I know use SCons for D. Given we are going SCons 2.5 → 3 I propose this is the time for breaking changes, so on reflection I think this change should be merged on the grounds of consistency with other tools.