Во-вторых, как вы собираетесь извлекать этот CSS из 500 Кб свалки файлов, расскажите?

Без особых проблем:

• https://github.com/theKashey/used-styles
• https://github.com/GoogleChromeLabs/critters

https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BF%D0%BB%D0%BE%D0%B2%D0%BE%D0%B9_%D0%BD%D0%B0%D1%81%D0%BE%D1%81#%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D1%81%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F
Да, но не совсем

1) Когда отапливается кондиционером — то это вообще полная жесть.

HeatPumps, или Ducted Air conditioners как их чаще называют тут, на каждый 1кв электричества дают 5кв тепла. Ими даже бассейны греют.
Плюс половина домов даже зимой могут питать кондеры с солнечных батарей, которых тут очень много

2) через несколько часов за окном меняется язык, менталитет, архитектура

Едем вверх — меняется — начинается "white australia"
Едем влево — меняется — там горы и старые города
Едем вниз — меняется — там больше зелени и раслабона

"Качество" местных "домов" — два термина в кавычках. Совершенно не понятно о чем думали люди когда строили себе жилье, но точно не о зиме (она тут есть), и не о лете (и она тут есть)

В Сиднее небо всегда голубое, море синее, а деревья зеленые.
Скукота

не из-за применения webpack, а из-за того, что это не настоящие модули

Конечно же это неправда, более того — неправда два раза

1. Не надо быть es6 модулем, чтобы использовать modulepreload
2. С последними обновлениями Chrome(>=76) делает streaming parsing для всех скриптов — https://v8.dev/blog/v8-release-78

Так что можно продолжать использовать старый добрый script.

Насколько я знаю Curiosity написан на state-charts, которые вообще не так чтобы язык программирования, зато надежности дает — огого! Boingи вроде летают на Rational Tau, которые в ядре своем — SDL диаграммы.

Окей — в Rust например система типов достаточно ясно дает понять, когда ты не прав. Но то никоим образом не защищает от того, что бы просто делаешь что-то не так чтобы очень правильно.

Именно по этому самые глюченный системы были написаны на строго типизированных языках.

Слои юнит тестирования не исключают друг друга.
Тем же датчикам надо ещё физические тесты устраивать, когда жестокая реальность(кривой пайки) потопчется по полностью протестированному коду.

Но ведь именно это главный аргумент сторонников TDD, которые были упомянуты в самом начале.
Если кратко резюмировать их логику — написание тестов отдельно/после кода требует сильно больше времени и сил через правильное написание кожа и тестов в параллель.
Те результаты статьи совершенно правильные — написание тестов классическим образом — пустая трата времени и денег.
Быть может их просто как-то по другому писать надо?

Уже более трех лет проживаю в Австралии и местные "нативы" с тобой не согласятся:

• о том что кто-то кому-то должен в одностороннем порядке
• лецмиспик фром мы хеарт(некоторые районы вообще по английски не бубу)
• их способности к вычитке

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

Просто открываем и просматриваем подряд все компоненты

Вот так делать не надо. Этот момент следует автоматизировать и показывать визуальные дифы, если они есть.

Если плана нет, это будет приводить к большому количеству исправлений, зачёркиваний (на бумаге) и переписыванию больших кусков кода.

По своему опыту могу сказать, что умение писать "по плану" является признаком плохого программиста. Это называется Остапа понесло.

Закрыть скобочку, вынести код во внешнюю функцию, зафиксировать интерфейс, написать тестик и только потом продолжить работу — в общем делать много исправлений — признак хорошего. Конечный код выйдет лучше и быстрее.

Разница тут как между нарисовать сову методом scan line, и "итеративным" классическим образом. Можно даже сказать — по agile.

Заметим, что единственная проблема была связана с тем что 54 пакет был использован более одного раза.
В начале надо было решить эту проблему, а потом уже менять версию пакета (просто потому, что это не всегда возможно)