raph brings up some interesting points regarding language choices in a new build tool. There are a few points here that I'd like to address.
First, in automake we always separated the implementation language of the tool from the language the user used to make things happen. There have been many requests over the years to blur this barrier, but I never regretted being firm here. Blurring this line basically means you must be very confident in your particular implementation, since giving access to it means it will be much, much harder to change.
My earlier questions were really ones about the implementation language of the tool. Is it ok to have a dependency on some other, larger project (Python or Perl or ...)? Of course that isn't a question with a fixed answer. It depends on what you want to accomplish. One of my goals is wholesale replacement of the auto* tools. This makes the question particularly hard.
The user's language is of course extremely important. We've all seen how autoconf's quoting and mix of m4 and sh is confusing and limited. We've all seen make's many syntax problems.
The tension comes because in some situations the user language has to have some power, and it is tempting to just use the same language for both. For instance, expressing autoconf-style configuration requires expressive power.
This is all "front end" stuff. I still haven't really started the front end design beyond kicking a few ideas around.
raph, I'd be interested in seeing rebar. How about sending me a tar file?