Toolchains, CMake configuration and "Configurations" — too rigid for real life?

Now CLion could have several CMake configurations («File | Setting | Build, Execution, Deployment | CMake»), but it looks like not enough for real C/C++ life (as opposite to Java life, for example). There are three interwinded problems, which asks me to use command line again and again instead of using CLion GUI. It is especially annoying in case of Catch unit-test runners!

First of all, «Name» of this configuration is passed as «-DCMAKE_BUILD_TYPE=xxx». So, I can not find way to have several different configurations which all have same type, but differ in other options. It is C/C++, after all, we are used to have tons of options for cmake / autoconf, which enable and disable and alternate different aspects of build! Now it seems impossible to have multiple build configurations with different user-defined options to select different implementations of features, used libraries, etc.

Second, project configurations («Run | Edit Configurations…») are linked to CMake configurations as one-to-one. So, if I could have two Debug configurations on CMake side (which I couldn't now!), I will need to create a lot of almost-identical Run/Debug configurations: one per component (for example, unit-test suite) per CMake configuration, which looks like O(N²) ;-). I could not have one Run/Debug configuration for my Catch tests, which I can run in different build configurations: Release, debug, with Win32 threading or POSIX threading (selected by CMake user option), a lot of variants in real-life project, really!

Third, toolchain is another hard option, which can not be selected in any CMake / Run/Debug configuration. Even IDEA allows to override JDK in Run/Debug configurations (which is not so useful in Java world, really!). But here if I want to test compilation both with 32 and 64 bit versions of compiler I need to re-configure whole IDE (CLion). It is very hard limitation! and in future, when clang will be officially supported, (I HOPE AND WAIT FOR IT!), it will be even more annoying.

All these problems together are especially acute when you start to run unit-tests. Yes, CLion Catch runner is very handy, but now I could really run test suite only in one configuration out of MANY I want to test! All other variants require me to change options back and forth, not with some drop-down selection, but with copy-pasting strings like "-DWITH_WIN32_THREADS=ON" and "-DWITH_ICONV=OFF" in configuration dialogs, which are not intended to be often used. It is very, very inconvenient. And CMake provide way to write GUI around these user-defined options! But no luck, even no luck to have several pre-defined configurations (see above).

Is here any plans to relax all these restrictions and make all this configuration hierarchy (toolchain → CMake configuration → Run/Debug configuration) more real-life-friendly?