Есть некоторые очевидные вещи, мешающие программистам-практикам, которые, возможно, не видны людям, входящим в комитет. Попытаюсь обратить на них внимание.

Объекты-значения

Большинству объектов не нужен скурпулёзный учёт вызванных конструкторов, потому что обычно объекты нужны, чтобы хранить значения, а не выполнять код конструкторов. Например:

auto a = b + c;
f(a);

Здесь незачем требовать от объекта вызов конструктора перемещения, потому что и так понятно, что этот объект больше нигде не нужен. Всякие RVO и NRVO надо оставить для классов, отмеченных специальным тегом, raii или типа того, а от всех остальных перестать требовать, чтобы они уговаривали компилятор не копировать лишний раз. Не так просто с ходу придумать пример, где бы эти лишние вызовы конструкторов были бы нужны. Может даже концепцию “значения” стоит распространить на вычисление выражений, string("asd") + string("fgh") - здесь ни к чему дёргать конструкторы с деструкторами. А ещё, возможно, так constexpr сможет получаться автоматически.

Очистка стека

Здесь уже не уверен, но, возможно, деструкторы можно вызывать раньше, чтобы не надо было в длинной функции оборачивать блоки в скобки. Было бы полезно для повышения читабельности кода и уменьшения промахов кэша. Иначе после рефакторинга

void f()
{
	...
	long_name(long_expression);
	...
}

получается такой код:

void f()
{
	...
	{
		auto a = long_expression;
		long_name(a);
	}
	...
}

В 4 раза больше строк, а хотелось бы только в 2. Опять таки, на объекты с тегом raii это не должно распространяться. Хотя тут ещё надо прикинуть, не приведёт ли это к путанице, а ещё есть опасность, что функция сохранит ссылку на объект и следующая функция этой ссылкой воспользуется.

Деманглинг имён

Сколько можно собирать Qt? Как меняется версия компилятора, так и собирай по новой, и у разных компиляторов разные dll, поэтому их нельзя установить в систему, каждой программе приходится таскать с собой. Но это тоже не простое изменение, у разных компиляторов разные стандартные библиотеки с разными структурами данных, для начала надо их унифицировать.

Библиотека компонентов

Это чуть ли не самое очевидное изменение. Почему у питона есть стандартные прикладные библиотеки типа json, xml и т.д., а когда хочешь прочитать json на C++, надо бегать искать нормальную библиотеку и пытаться подключить. Уже бы сделали standard application library или типа того, чтобы в винду потом складывать sal_crt.dll, sal_xml.dll, sal_json.dll и т.д. В sal_crt проксировать вызовы msvcrt, и тогда не надо будет напрягаться с поддержкой на разных версиях винды. За одно сдуются размеры бинарников, если все будут использовать одни и те же библиотеки. И здесь незачем гнаться за мегаскоростью и т.п., надо сделать стандартный интерфейс с модульной нарезкой, а если кому нужна хитрая мегабыстрая обработка с вызовом мегакривых функций, тогда пусть подключает сторонние библиотеки. Ну и конечно, сами библиотеки должны быть сишными (с нормальными именами функций то есть), глядишь, и другие языки на них пересядут. Пишешь pic install requests и получаешь библиотеку requests с помощью Pack Installer C - удобно же?

Код, запускаемый на этапе компиляции

Рефлексию пытаются добавить костыльными способами, вместо того чтобы прямо сказать, чего хотел автор. Как это могло бы выглядеть:

Заполнение на этапе компиляции

float cos_table[100];
compile_time {
for (int i = 0; i < 100; ++i)
	cos_table[i] = std::cos(i);
}

// вычисление на этапе компиляции
struct crc_string {
int value;
crc_string(char* v) {
	compile_time{
		this->value = crc(v);
	}
}
}

Контейнеры с типами, чтобы не мучать компилятор шаблонами с переменным числом аргументов

compile_time {
	auto parser_types = { int, float, std::string };
}

template <class T>
void f(T t)
{
	compile_time {
		// проверка наличия типа в списке
		if (parser_types.contain(T))
			... //какие-то проверки

		// просмотр членов класса
		if (t.members.contain("some_member_name"))
			...
	}
}

Кодогенерация

void g(int t_id, char* value)
{
	switch(type_id(T)) {
		compile_time
		for (c : parser_types) {
			execution_time { // строки в блоке добавить в код
				case type_id(c):
					some_func<T>(value);
					break;
			}
		}
	}
}

Не знаю правда, как это потом отлаживать, но с шаблонами же справились.