Hello, all, and especially Jules!
As I sprint to the end of my current project, things become more obvious to me. In particular, I was very quickly able to live with .jucer files (once I wrote some scripts to manage 'em for me of course :-D) and a lot of the things I wanted, like the ability to use environment variables or something like that as part of the various flags, would still be nice but don’t add a huge burden at all.
However, there is one thing that sticks out like a sore thumb, and that’s that extraLinkerFlags is defined per platform and not per configuration.
For example, here’s the extraLinkerFlags from my current project:
extraLinkerFlags="-L…/…/…/…/…/build/debug/libcddb/lib -lcddb -L…/…/…/…/…/build/debug/gflags/lib -lgflags -L…/…/…/…/…/build/debug/glog/lib -lglog -L…/…/…/…/…/build/debug/gtest/lib -lgtest -lgtest_main -L…/…/…/…/…/build/debug/iconv/lib -liconv -L…/…/…/…/…/build/debug/mpg123/lib -lmpg123 -L…/…/…/…/…/build/debug/protobuf/lib -lprotobuf"
You can I hope see the issue - that this works fine as long as I only do debug builds, but when I start doing release and debug builds I’m going to have to do a lot of work, editing and re-editing this file (or figure out a way to have manage two copies of this file, identical except for that one field).
I don’t see any reason why there shouldn’t be two sets of extraLinkerFlags, one platform-specific and one configuration-specific.
By the way, not to fawn too much 
but the build Jucer is a really, really good idea and works extremely well even if rough around the edges.
My vision of what the ultimate “build JUCER” could look like is much clearer these days, in fact, and it’s rather a lot like the one that’s there already with a couple of minor changes.
As I think I’ve already suggested, one change would be some sort of parameter or variable substitution into the settings flags (so -L…/…/…/…/…/build/debug/gtest/lib would become -L{BUILD_ROOT}/gtest/lib)
And the other is that all the settings be settable potentially at three levels: the root of a project, on a per platform basis, and on a per configuration basis (this is a generalization of my feature request in this missive…)
It would be hard to actually have enough GUI space to represent all of those choices - so you don’t have to! As long as the editor preserves parts that it doesn’t actually display, it’s fine if only the XML language supported all of these values.
Looking at your code, it’d be pretty easy to have a single big “settings” class that you attached to all three levels which was basically the union of all the settings that you have at the three levels of platform, config and “top” - and not, actually, change the current GUI at all. (I’m always in favour of changes where you can change one side entirely and not change the other at all.)
But… it’s scarcely needed. I don’t see huge use for anything other than the linker flags, really, except for specialized cases. I’m sure I’m not the only person who makes debug and release builds though…
And actually, having a set of configuration variables you could substitute would even fix my extraLinkerFlags issue, wouldn’t it?