Of course, many of these are a question of the conventions and standards applied to the pieces of the build. A build system is both the framework and the pieces written for that framework. zc.buildout has an okay framework, but it didn't follow these conventions of error handling, it didn't make following these conventions easy, and the initial recipes didn't follow this convention. So of course it's unsurprising that later recipes wouldn't go to great trouble to follow these conventions. Similarly BuildIt never goes out of its way to enable careful error checking.

In other cases fassembler also goes to more length to make errors understandable, like storing all log messages so that if you hit an error you can see the highest level of verbosity, without having to always run at the highest level of verbosity. This makes it easier as a task author to write useful messages without overloading the user. Or in the case of a template substitution problem it'll show you the complete context in which the template was rendered as well as the template source, which makes it easier to debug (and is something I would have found very useful in BuildIt).

You can define this as outside the scope of the tool, but I think you would be wrong to do so as it's among the most important things a build framework should provide, with supporting tools and with good examples of how to do proper error handling. Just because it's not a clear feature or piece of code you can point to, doesn't make it outside the responsibility of the system.