Почему умирает OpenHarmony

Если вы откроете проект на gitee.com вы увидите что проект включает в себя больше 700 (семисот!) репозиториев. Секрет в том что ни один из этих проектов в отдельном репозитории не компилируется независимо! Один знакомый разработчик, который работает с этим богатством, рассказал мне, что чтобы скомпилировать какой либо из проектов составляющих OpenHarmony вы должны скачать и скомпилировать минимум 450 репозиториев! Дело в том что даже отдельные приложения такие как mailBox, storage с СМС-ками, с контактами, видео плеер, ... которые, казалось бы, должны быть отдельными приложениями таковыми не являются. Они все компилируются как части одной монолитной прошивки смартфона (как части операционной системы) и вы не можете скомпилировать их без компиляции всей системы, такая опция просто не предусмотрена.

Поэтому OpenHarmony превратилась в огромного монстра который уже не может даже шевелиться от собственной тяжести. Внутренние связи и зависимости между функциями приложений и зависимостями ядра и системных библиотек никто не контролирует, они постоянно дублируются все в новых и новых модификациях, входят в противоречие друг другом, генерируют противоречивые потоки данных, копии данных, несовместимые интерфейсы, ... все это подобно раковой опухоли которая разъедает-разрывает носителя изнутри.

Каждый новый добавленный в OpenHarmony репозиторий приближает видимый крах проекта.

Интересно как обстоят дела у Андроида в этом смысле.

Прочитал тут заметку про красоту замыканий и у меня появились смутные сомнения по поводу того, как появилось эта, в разных смыслах, положительных и отрицательных (я не к тому, чтобы встать на какую-то сторону, я за разумное разнообразие), хитрая техника построения кода.

В большинстве языков является естественным распространение области видимости переменных из внешнего блока во все внутренние блоки кода. Приведу пример, чтобы не было сомнений (псевдо-код намеренно нарушает синтаксис известных мне языков, чтобы не быть отнесенным явно к одному из них):

Function(type par)
{//outer block(see“inner block”father)
  Int X = 123;
  If(par == someConst)       
  {//inner block
	We can use X here!
  }
}

Определение для Лямбда-функции тоже создает внутренний блок кода:

Action Function(type par)
{//outer block (see “inner block” father)
  Int X = 123;
  If(par == someConst)       
  goto Label; //we need goto just to escape definition of extra inner block
  Return lambda=>
  {// inner block
  some code that uses X in the block
  };
Label:
  We can still use X here!
}

Интересно! Это только мне кажется, что передача переменных из окружающего кода в код Лямбда-функции, ВОЗМОЖНО, изначально была ошибкой при разработке компилятора, когда стандартный способ распространения области видимости переменных по недосмотру применили к вновь появившимся инлайн реализациям функций? Но потом кто-то нашел применение такой возможности и, как это часто бывает, «Бага»(bug) превратилась в «Фичю» (feature)?