Это возможное решение, но при условиях:
* человек который это говорит, достаточно старый чтобы застать Clearcase , svn ,perforce.
* У вас в команде есть отдельный человек, который делает эти мерджы и больше ничем не занимается.  И постоянно мониторит разные бранчи. То есть он автоматом аплаит изменения, а если что то не так, зовет авторов. И постоянно отслеживает что изменения из младшей ветки, обязательно есть в старшей.

На сколько нибудь большом проекте (а у вас очень большой проект) поддержка несколько бранчей это ад. Поэтому и был придуман CD. Ну а не рабочие/неготовые фичи просто выключаются флагами.

У нас в мере/нортеле была поддержка двух бренчей на клиаркейсе. Брр.. Получалось я не мог нормально писать код и рефакторить, ибо это надо бэкпортить на разные бренчи. В результате говнокодность резко возрастала 😞
Основным камнем преткновения была база данных. Которая по сути была бинарным конфигом с перекрестными ссылками. Добавить байт в неё было не возможно. Для этого надо было фризить все бранчи на пару месяцев. Приходилось искать не используемые биты и туда распихивать нужную информацию..

А причем тут консенсус? Можно узнать зачем понадобилась эта задача на практике?
Вообще, эта задача из метрологии. наверное есть учебник. Я студентом на первом курсе немного подрабатывал в этой стезе (расчет потребленной воды / тепла, с помощью манометров и дифузора),  но мне на пальцах объясняли как должен действовать метролог, ну и как считать правильно.

ну вот один не варинт когда надо несколько версий поддерживать, а у нас теперь еще и lts появились

А кому надо несколько версий поддерживать? Разработчикам не надо...
Иногда бывают простые хотфиксы.. А иногда бывает, что фиг ты замержить в две разные ветки. Код слишком сильно отличается

При этом передавать значения - дорого. Например, в той постановке достаточно передать 1 бит от Алисы к Бобу, чтобы консенсус существовал

это как? Что это за бит такой?

Консенсус при том, что необходимо прийти к общей, идентичной оценке величины. На практике - в распределенных системах такое надо. А эта оценка, например, задаёт поведение протокола. И если она отличается у двоих, то и протокол у них будет отличаться, что проблематично.

вот у тебя один намерил 10.1, а второй 10.2. Как от этого поменяется протокол?
Если у тебя система не вырождена, то на дольнешие вычисления это не влияет  (забыл правильное слово, в общем есть системы где ошибка накапливается, а есть, где остается в тех же пределах). В линейных системах она определяется через собственные числа.

Кстати, почти все 3G/4G вышки гуглятся через сайт вроде Роспотребпозора, где СанПин требования по безопасности излучения сертифицируются. Я так вокруг дачи нашёл, в каких деревнях чьи вышки. Даже высота передатчиков над уровнем земли и диаграмма направленности описаны.

По протоколу например необходимо повернуть налево, если t<10, и направо, если t>10 :)

Сложно объяснить. Но попробую. Фактически, алгоритм нахождения верхней и нижней оценок строится как сетка с шагом в несколько погрешностей. На каждом из подинтервалов выдаётся определённое значение. Но проблема в том, что значения t_a и t_b могут оказаться по разные стороны от точки сетки при любом разбиении. Решение - сделать две сетки (вторая сетка со сдвигом от первой так, что если значения оказались у границы первой сетки, то у второй они окажутся внутри интервала гарантированно), и бит как раз говорит, какую из двух сеток использовать.

это понятно. выше же и вариант- мержы елси не слишком много конфликтов

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