This is like a clean, simple reincarnation of make. And it is fascinating how it works:
Make is essentially a configuration file which textually describes a directed graph (DAG) of dependencies by their path names, together with embedded shell command lines which build each dependency.
This works more or less well, but if some dependency is missing, one has to add "make clean" commands. Or maybe, just to be sure, "make clean" (which would not be necessary if the tool really unambigously defined the build). Or for example if a system library has changed. Or if an optional dependency appears which was not there before.
And it becomes more complex if build steps run in parallel. Therefore, things like "make config" and so on are needed.
Redo turns this inside-out: It uses real shell scripts for building stuff, together with special shell commands that define dependencies. And these commands have dependencies as input, they can for example use what the compiler tells them. (The background is that e.g. in a complex C project with lots of #defines, only the C compiler has a precise picture what it needs). The top-level command runs all these build scripts in the right order. (In fact, they could also be written in Lisp, Java or Guile or whatever, as long as they support the common dependency-defining commands.)
The resulting system is surprisingly simple.
One quality for example is that in a source tree, definitions can be build recursively without any special provisions. No top-level Makefile required.
Definitely a high usefulness-to-complexity ratio. But IMO the core advantage of Make is that most people already know it and have it installed (except on Windows).
By the time you need something complex enough that Make can't handle it (e.g. if you get into recursive Make) then you're better off using something like Bazel or Buck2 which also solves a bunch of other builds system problems (missing dependencies, early cut-off, remote builds, etc.).
However this does sound very useful for wrangling lots of other broken build systems - I can totally see why Buildroot are looking at it.
I recently tried to create a basic Linux system from scratch (OpenSBI + Linux + Busybox + ...) which is basically what Buildroot does, and it's a right pain because there are dependencies between different build systems, some of them don't actually rebuild properly when dependencies change (cough OpenSBI)... This feels like it could cajole them into something that actually works.