​​

I would recommend using C++ and Python, exclusively, for everything.

Logically, C++ as the core development language is a sane standard - so I won't over-explain what's already been said.

Now, I don't personally like Python - even with my opinion of it however, I'd say it is a defacto standard for a scripting language - easy to learn, easy to use, fully featured, and reliable.
bjam / DSL, or any other custom solution is a step backwards - it adds more for a developer to learn, comes with complications beyond usage, arguments regarding syntax, etc.
Python is easy to pick up for experienced developers, and a simple language for non developers to edit.

In short, 

C++ as a core means speed and reliability.
Python as an extension means the User-facing component is reliable and simple.

If the user needs to parse XML files to generate build targets, Python allows that to be implemented and keeps such clutter away from the core build system.
Further, as many have asked for IDE integration, such integration can be written by users familiar with the IDE as extensions in python - meaning that more collaborative effort can be done without needing to be a robust expert in the Build-systems core development.

I agree with Stefan in that we should avoid the nightmare of "supporting more than one language" - with a small caveat. One I think should be discussed here.

It's my opinion that the future boost-build should have a C++-API, such that with minimal inclusion of a header, a C++ plugin can be presented with access to the equivalent functionality of the python-bindings - This would allow for vastly more powerful extensions to be created leveraging inter-process communication as well as integration into other mediums.
Examples of such exposure would be direct-communication with webservers, IDEs, and other build systems. (Imagine a Apache-plugin that provided real-time build-status for large projects for example). On windows especially this would allow tight-integration with Visual-Studio via .Net/COM.