​I cannot express enough the importance of both the concept of storing build-states, as well as the transitional data during a build.

There is no scenario as offensive to the senses as walking into work on Tuesday to be told "The version from Friday doesn't work, fix it" - Any programming house with a QC department has to deal with a simple and essential issue. People that are not programmers have to test your software - often some time after it was built.

The ease of automating the build process is only half the life-cycle of a build system, providing an interface through which build-states and errors can easily be retrieved is essential - often the tooling for such a scenario is done in house, presented as a intranet page to the QC staff.
In these situations Developers need feedback as to the build state, if possible before QC are aware a build has even been made - and in the event of failure, knowing what failed means knowing who needs to solve the issue.

In my companies scenario, we have fourteen software products - the nightly build system provides these as windows installers as well as Apple-DMG files.
Often errors are caused by simple network problems (system-admin issues), but some of our software is compiled with six different languages, through four different build processes - each has a different developer responsible.

I'm certainly not proposing a build system be some cure-all to these issue, however being capable of programmaticaly retrieving the state of a build, as well as the cause behind a failed build is a feature that should be seriously considered.