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

В чужой монастырь со своим уставом не ходят. Пишите на паскале, там хоть с -100 или с true можно начинать массив.

И 2МГц, и 12МГц, и 33МГц. Перестало быть актуальным на персональных компьютерах где-то в эпоху Пентиумов. А на бесчисленном множестве контроллеров актуально до сих пор.

Но в итоге это стало больших рассадников багов(не забыть писать Count-1 и т.п.) и потерь человеческого времени, т.к. человеку привычнее считать с 1

Хм. Насколько я знаю, человек привыкает считать массивы с 0 где-то ко второму месяцу обучения программированию :) Кроме того, контроль границ массивов в языки пришёл ещё в 1980-е, а чуть позже и циклы foreach. Так что проблема явно надумана.

Зачем писать Count-1 ??? Если мне надо пройти 10 элементов массива то:

for(uint8_t i = 0; i < 10; i++) {...}

А если бы начиналось с 1, то пришлось бы писать 10 + 1. Т.е. сейчас мне не надо писать count-1, а пришлось бы писать count+1 если бы всё было так как вы предлагаете.

Ой вы не правы про ряд натуральных чисел.
Без нуля он неполон и убог.

Я продолжу:
3) array[i*N+j]

Наличие контейнеров из коробки в плюсах не заставляет вас ими пользоваться. Это ж не Go без дженериков, можно написать свои.

Лично меня не заставляет, а вот про условных коллег из другого отдела я так сказать точно не могу.

Более того, в С из коробки есть, например, сортировки, зачатки парсинга, зачатки работы со строками, и так далее. Довольно странно апеллировать именно к контейнерам.

Все перечисленные функции реализуются в модели типов языка C, а не являются особо специфицируемой надстройкой над ними. И парсинг, и сортировки, и что угодно ещё - это просто определенные действия, совершаемые при помощи указателей на области памяти (на функции или данные), а не абстракция, которая может быть реализована разработчиками компиляторов, строго говоря, практически как угодно.

А, к слову о низкоуровневой конкретности, наличие темплейтов позволяет писать код так, что компилятору куда проще его оптимизировать. Массив из 5-10 элементов на плюсах сортируется раз в 40 быстрее, чем на С, просто за счёт отсутствия оверхеда из-за непрозрачного void*.

Тем не менее посмею заметить, что погоня за производительностью за счёт усложнения системы - не лучший путь. Как правило, системные программы должны работать не как можно быстрее, а в срок выполнять каждую задачу (ведь это требование к системе реального времени, а связка ОС+драйвера является как минимум системой мягкого реалтайма).
А усложнение системы во имя ускорения... похожим путём уже ходили CISC-процессоры, и в итоге пришли к системе микрокоманд (практически RISC-внутри-CISC).
Предположу (возможно, ошибусь), что идеальным для компиляторов было бы не "уход вверх", в "высокий уровень", а наоборот, написание программ командами сразу под какую-нибудь виртуальную машину, такую как JVM, LLVM или например Форт-машина. При этом почему-то так мало кто делал (возможно конечно, что по исключительно историческим причинам), и в том числе поэтому сейчас мы получаем LLVM-компиляторы классических языков программирования, где изначально ничего такого не задумывалось ни сном ни духом.

Потому что Томпсон заменил выкидываемый Multics именно на UNIX (в 18к оперативки), а другим понравился именно его подход. При этом тогда был де факто оупенсорс и система была почти везде - поэтому ее начали копироывать.

Правильная постановка утверждения: если бы не было Томпсона, Ричи, университетского оупенсорса и юникса, то роль linux занимала бы другая система.

P.s. а Multics на момент принятия решения Томпсоном был недостаточно портабельным и слишком монструозным.

Отлично, но абстракция «всё есть файл» в UNIX пришла из Multics, где применялась ещё шире — блоки памяти тоже были файлами

Основным отличием Unix от Multics был, насколько я помню, Kernel Panic вместо обработки исключительных ситуаций. Дело в том, что больше половины кода Multics составляли именно алгоритмы обработки ошибок. Поэтому создатели Unix не мудрствуя лукаво решили примерно в таком ключе: "все равно много проблем можно решить простой перезагрузкой, поэтому не будем усложнять"

И в этом смысле иронично, что

но DOS и Windows были бы?

точно не являются правдой на 100%, ведь Windows знаменит прежде всего своим аналогом Kernel Panic (я сейчас, конечно же, про BSOD), который был основным отличием самых первых юниксов от мультиксов.
Примечательно, что именно по причине ненадобности в C не внесли никакой обработки исключительных ситуаций, кроме кода возврата ошибок errno. И в этом плане Unix оказал значительное, историческое влияние на вычислительные системы в целом.

В DOS же файловая концепция никсов зашла уже через пару лет после её создания, ко второй версии. До этого там была сугубо СР/М-ная архитектура. Поэтому она вполне существовала бы и без влияния UNIX, просто развивалась бы в другом ключе. Ну а Windows вообще зашла с другой стороны, изначально как GUI над существующим DOS API.