Имхо, тут конфликт универсальности (поддержка полного набора Unicode) vs оптимальности по памяти/быстродействию. Для интернационализации нужна поддержка Unicode, для конфигов/данных может быть достаточно ASCII. Так что я сомневаюсь, что удастся избежать конвертации строк. Грубо говоря, как сейчас std::wstring <-> std::string.

По-моему, вы гипертрофируете проблему.. Я понимаю, если это было bottleneck место в коде.. Ну т.е. оно того стоит? Ну я, просто не в курсе..

Думаю все зависит от того будет ли Qt заниматься/поддерживать свои контейнеры. Если нет - то рано или поздно они будут "поглощены", ну это судьба всего что прекратило развитие. А если да - беспокоиться не о чем.

Моя главная проблема с Qt контейнерами - что мой отладчик не показывает их содержимое Аргументы в пользу std мне кажутся весьма неубедительными. Ну тот же QString - да по удобству использования std::string и рядом не стояло. Да бог с ним, с уникодом, попробуйте написать неск простых ф-ций-утилиток - и Вы сразу ощутите что нужных, удобных ф-ций под рукой нет, придется постоянно лезть в итераторную мудистику.

Или QList. Слышал мнение что, мол, теперь, когда есть крутой move (все чего-то "мувят") QList уже ничего не дает, только оверхед. Позвольте, а как хранить неперемещаемые данные? Насколько мне известно, какой-то "официальной" альтернативы в std нет, придется использовать вектор указателей. Это далеко не так удобно, хотя, справедливости ради, и предоставляет больше возможностей

Как хорошо, что вы перешли в практическую плоскость.
Но тут про удобство я вообще не понял. Какую сторону вы топите - QString или std и где и в чем заключается удобство.



Вообще не понял. Т.е. смысл понятен, но интерпретаций с моей стороны куча.
Давайте уберем свистелки - перделки, которые мы засовываем в контейнеры - аля чето-там с гуи или свои пару значений. Мы ими пользуемся (контейнерами) по удобству (в данном случае), а не по функционалу. Ну если мне удобней map использовать для своих пару значений, чего я буду выслушивать крики что: "вектор или лист быстрее будет". Да это вообще не имеет значение.

Итак, свистелки откинули, более "большие" массивы - т.е. алгоритмы.
И тут мы приходим к следующему - те, кто пишет реальные алгоритмы они пытаются сделать структуры данных как раз не перемещаемые - т.е. нету там указателя на внутренние данные, яркий пример std::string, где большинство строк влазит во внутреннюю структуру. Ведь вызов new/delete мало того, что требует ресурсов, так ещё и располагает данные неизвестно где в памяти, а не рядом.

List, не смотря на теоретическое очевидное преимущество в производительности на практике сливает вектору.
И даже копирование данных в векторе, расширение вектора во многих случаях лучше чем лист.
Связано с 2 вещами:
1. Вектору не нужно заниматься выделением памяти (кроме рассширения). Аля стек по сравнению с кучей.
2. Данные, которые хранятся в векторе (если это не поинтеры) расположены рядом, и кеш проца просто отлично с ними работает.

Но,  конечно, это накладывает ограничения: данные живут в векторе, он их владелец. НО! на то они и алгоритмы, чтобы работать с массивами данных, а получать оттуда ссылки.

В принципе, разверните, что вы хотели сказать, может я не в ту степь пошёл и пишу "бред".

Никого не "топлю"  , просто говорю что мне QString куда удобнее. Ну хотя бы нужно "обрезать" альфа-символы в начале и конце строки. Это не так уж просто с std::string. Поиск, замена и многое другое в QString намного лучше, просто больше полезных вещей (ну или "плюшек"). А не хотите плодить строки (всякий раз выделять память) - есть отличный класс QStringRef

Даже если бы и так - о том что std::string он "тем более перекрывает" Вы конечно благоразумно умолчали 

Достоинства вектора никто не умаляет, он самый популярный контейнер, и в любом проекте обязательно найдутся данные для него, рискну даже утверждать что их будет большинство. НО, помещая туда данные, мы соглашаемся с их "перемещаемостью", т.е. в общем случае адрес эл-та вектора хранить нельзя. Приходится хранить индекс, но он, в отличие от указателя, "не самодостаточен". А если еще есть вставки/удаления - то индекс вообще не годится. Короче, если данные - "хорошие" структуры, на которые ссылаются другие, то вектор не годится, тогда где их хранить? Иногда в мапе/хеше, но не всегда. Вот и выплывает идея QList, по-моему вполне разумная. Конечно можно спорить что "перемещаемо" а что нет - но сути это не меняет

Только вроде беду с const решили, а тут новая напасть... негде хранить "хорошие" структуры. Жесть.

В qt6 будет SSO. Так-то негоже ломать совместимость каждые полгода, а SSO требует нарушения BC. Почему в Qt5 не добавили, отдельный вопрос, но патч уже вроде бы тогда был.