Добавить в стандартные контейнеры вроде std::vector и std::list функцию subelements, которая будет аналогом std::string::substr.

адаптер для range-based итерации по контейнеру с удалением элементов

Есть идея внести в язык обособленную сущность под названием "интерфейс".
Под словом "интерфейс" тут подразумевается таблица виртуальных функций, аналогичная той, что есть у классов, только без данных.
Соответственно, у интерфейса нет скрытого параметра "this". Но можно с помощью конструкции using вызывать методы интерфейса в стиле миксинов. Так-же, я думаю, можно делать некоторые "zero cost" абстракции.

The main, semantically lacking, boilerplate in the usage of the `std::move` today is for the sinking of variables that we no longer need, especially locally. It's not like the `std::move` for a transfer of ownership, but a suggestion to make an optimized copy. This proposal is similar in spirit to the current behavior of return statements, which are effectively xvalue expressions in cases when they can't be elided if an automatic storage duration variable is returned.

Сейчас поведение неинтитивное, хочется получить ошибку компиляции

Расширить name lookup, чтобы вызовы вида "classInstance.classMethod(args...); " "искались" не только, как "ClassType::classMethod(args...)", но и как "classMethod(ClassType &, args...)".

auto ptr = func() ?: otherPtr;

Сейчас в списках инициализации инициализируемые сущности могут быть записаны в любой последовательности, однако реальный порядок инициализации от этой последовательности никак не зависит, что провоцирует возникновение дефектов в программах.

Несоответствие объявленного типа таких параметров фактическому (например в int foo(int action()) параметр action - это указатель) затрудняет работу с ними провоцирует возникновение дефектов в программах.

Хотелось бы помечать некоторые функции классов из стронних библиотек (например, Qt) помечать как [[deprecated]] для того, чтобы их нельзя было использовать.

Сделать возможной перегрузку operator.