Никогда они это не поправят, там всё растёт из совместимости с предыдущими системами, а не от продуманной идеи текстового интерфейса программ.

Консоль — это терминал (его эмулятор), оболочка, системный API, утилиты. В десятой версии подтянули терминал, добавив украшательства, сочетания клавиш, работу с буфером, изменение размера на лету и прочее, что давно считается нормой в нормальных ОС (и уже было в альтернативных консольках под винду). Интерпретатор умнее не стал: нет смысла придумывать свой bash, которым никто не будет пользоваться. По той же причине удивительно ожидать, что стандартные утилиты вдруг перепишут, убрав жёсткую привязку к досовской кодировке. Заметим, что у нас операционная система насквозь юникодная (по крайней мере, API), системная локаль соответствует кодовой странице ANSI, а консоль работает в OEM-кодировке, и приложению надо все три варианта иметь в виду при вводе-выводе. "chcp 65001" официально не рекомендован (поскольку UTF-8 в винде не родной формат ни для чего, а это, видимо, хак для представления его в качестве одного из MBCS) и приведёт к глюкам и молчаливым падениям случайных программ (особенно кросплатформенных). Я когда-то давно поковырял это всё и пришёл к выводу, что однозначно рабочего решения не существует: если в юниксовых программах и библиотеках на C можно добиться, чтобы массивы однобайтных символов в качестве базового формата передавались без изменений, а потом объявить эру .utf-8 и заново проверить, что никто не считает, что длина строки в символах равна количеству байт в ней, то тут и программа должна внутренние форматы приводить к wchar_t, а потом ещё консоль как-то будет символы конвертировать, в зависимости от кодировки, шрифта (!) (! даже без вывода на экран, при перенаправлении в файл/из файла (!)).

Можно всё переписать заново, пользуясь только низкоуровневыми функциями, но взаимодействие с другими консольными программами вернёт пробелму на место. Можно использовать POMERSHELL (там ввод-вывод программ насильно превращается в объекты .NET) или другой язык с GUI'шной консолькой и надеяться, что их авторы насчёт кодировок всё предусмотрели. Можно, как cygwin, брать полноценный putty и подключаться к полноценной оболочке в воссозданном полноценном окружении.

@romme Два замечания:
— Я бы посмотрел на человека, сознательно пользующегося ANSI-обёрткой к API в 2015 году.
— Конвертировать внутри приложения можно сколько угодно, это автоматизируется, и это всё равно придётся делать, потому что utf-8 винда не понимает.
— Проблема в том, что весь этот правильный юникод в правильных вызовах API нормально отображаться и вводиться не хочет из-за отсутствия родной поддержки в оболочке, библиотеках, фреймворках и прочем: https://alfps.wordpress.com/2011/12/08/unicode-part-2-utf-8-stream-mode/