Не, Максим. Решать задачу нумерации несвязанных подграфов данного графа в Power Query - то ещё удовольствие. К тому же Всеволод как всегда пример данных представил в стиле - нате...
Если хочется порешать головоломку, то прикладываю более тяжёлый пример. Из левой таблицы нужно получить правую.

Ну вроде сделал, но на длинных цепочках может очень сильно тупить

Код

// order let    Source = Excel.CurrentWorkbook(){[Name="order"]}[Content],    #"Changed Type" = Table.TransformColumnTypes(Source,{{"Заявка", Int64.Type}, {"Контакт", type text}}) in    #"Changed Type" // order (2) let    Source = order,    Grouped = Table.Group(Source, {"Заявка"}, {{"tab", each _[Контакт], type list}}),    Contacts = List.Buffer(Grouped[tab]),    Orders = List.Buffer(Grouped[Заявка]),    Pos = List.Buffer(List.Positions(Contacts)),    fnCombinator = (modContacts as list) =>        List.Transform(            Pos,            (p)=>List.Accumulate(                modContacts,                modContacts{p},                (s,c)=> List.Union(                    {                        s,                        if List.ContainsAny(s, c) then c else {}                    }                )            )        ),    First = List.Buffer(fnCombinator(Contacts)),    Second = List.Transform(fnCombinator(First), List.Sort),    temp = Table.FromColumns({Orders, Second},{"Заявки","Контакты"}),    GroupedContacts = Table.Group(temp, {"Контакты"}, {{"Заявки", each _[Заявки], type list}}),    IndexClients = Table.AddIndexColumn(GroupedContacts, "Клиент", 1, 1),    ExtractedContacts = Table.TransformColumns(IndexClients, {"Контакты", each Text.Combine(List.Transform(_, Text.From), ";"), type text}),    ExtractedOrders = Table.TransformColumns(ExtractedContacts, {"Заявки", each Text.Combine(List.Transform(_, Text.From), ";"), type text}) in    ExtractedOrders

я решал исходную задачу, где один столбец - номер заявки, второй - контакт, имеющийся в заявке.
Логика такая: группируем по заявкам, получаем список списков контактов.
Дальше бежим по этому списку:
1. Берем первый элемент (список контактов первой заявки)
2. Последовательно проверяем, есть ли пересечения с другими списками: если пересечение с конкретным списком есть, то объединяем списки, запоминаем этот список, и проверяем следующий.
3. Проверяем второй элемент и запускаем п.2
4. и так проверяем все заявки.
Например, есть список {{1,2},{2,3},{4},{3}}
Первая пробежка даст результат {{1,2,3},{1,2,3},{4},{2,3}}
Запускаем пробежку еще раз, получим {{1,2,3},{1,2,3},{4},{1,2,3}}
В итоге там N^2 на первой пробежке и N^2 на второй, что супер далеко от оптимального. На больших списках это малореально.

Затем группируем таблицу "Заявка"-"Список заявок" по обработанным спискам, получаем пару: список заявок/список контактов, одна пара = 1 клиент.

Я думаю, здесь всё дело в исключительной жадности моего алгоритма. На 10 заявках это 200 циклов по списку заявок, на 100 заявках это 20000 циклов, а как правильно посчитать сложность алгоритма - не знаю, наверное это O(2N^2)
Быть может, есть менее жадный алгоритм объединения множеств по условию пересечения?

И я подумаю на досуге...   граф в дерево - звучит интригующе... спасибо за пример...
но #8 - код на Серверном SQL, полагаю...  

С графами не работал, но фразу "Выявить все возможные комбинации." понял. Максим Зеленский, Учел ваше замечание в новом посте. Как я понял, в примере в данном посте был представлен маленький набор данных. Если что-то не так, готов еще учесть замечания Ваши.
Пример на T-SQL правильно я понимаю, что сет данных выгружается куда-то, потом стороннем приложением прогонять через запрос к БД? Вы выше написали, что в SQL задача не чуть не легче, для понимания, почему решили на SQL привести пример?
Максим Зеленский, прочитал логику что Вы описали не могли бы Вы выложить пример, интересно изучить как Вы в цикле делается возврат ко 2 пункту. Благодарю.

Еще хотел узнать, а если задачу упросить например вложенность до 4 пунктов макс, то тогда проще всего просто сделать 4 раза merge?
Благодарю за помощь!
 

Хм... да нормально собирает, получаем в итоге 2 клиента, {1,2,3} и {4}

32-битный Excel вешает процессор надолго (что вообще непонятно, не должно так быть, наверное, пресловутые promises в List.Accumulate дают прикурить), но 64-битный Power BI решает быстрее. С ростом количества элементов списка O(N^2) дает себя знать, конечно.
Если вы про пример на T-SQL, то это для меня темный лес, увы.
А кода недостаточно? Цикл по заявкам обеспечивается List.Transform,  внутри каждой петли цикла используем List.Accumulate для нахождения связей текущей заявки с остальными заявками.
Там, конечно, можно оптимизировать чуть-чуть, убирая текущую заявку из рассмотрения, но это не принципиально.

Благодарю, буду изучать.

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

продолжу свою мысль - раз ТС не даёт своих пояснений... Если вы хотите пользоваться удобствами Реляционных Структур (даже Сущность создаёте) - показали бы Схему вашей БД в той части откуда и куда и КАК вы связи настроили... а то вы жалуетесь что у вас связи рушатся, а нам гадай какие (исходя из целей ведения вашей БД) - что у вас там за связи и что за Сущность БЕЗ Ключей   ... - и может вообще др. подход оптимальнее, чем ваш...
даже цели   не совсем понятны: вы хотите проследить судьбу Клиента по смене его контактов? (он вам дал разрешение на собирание личной инфо о себе?)... или же вы всё-таки хотите проследить судьбу Заявки?...
p.s.
думаю без схемы БД и адекватно сформулированной сути ваших затруднений - сложно дать вам совета об Оптимизации... хотя по сути вы его уже получили: хотите мониторить Клиента - дайте ему Id (как primary key) - иначе вам придётся это делать в оперативке каждый раз как захотите хоть какую выборку по клиенту... выделяете его в объект для  мониторинга - так и создайте его Сущность - таблицу Клиентов... или делайте это каждый раз на лету... вам удобно?
p.p.s
вобщем судьбу контакта и судьбу заявки я вам прикладываю - (на примере из #3 - табл Отчёт не участвует) ... как и ДЛЯ ЧЕГО вы там хотите связи достать - не вникаю... а для мониторинга судьбы Клиента создавайте другую сущность... и желательно с пониманием (и вашим и помогающих по пояснениям от вас) природы ваших сущностей, связей Нужных (не нужных не надо), ваших целях (а не обрывком из контекста БД) И Целостности(!) вашей БД и ключей настроенных вами исходя из ваших целей...
(Только уточните у клиента согласен ли он на такую слежку за собой)...
==================
P.P.S МОДЕРАТОРАМ: слетают вложения, когда пишешь 2-й пост (в нём дублем появляется вложение из предыдущего своего - удаляешь - исчезает и из предыдущего поста)... не удаляешь - 2-й пост не опубликовывается...

Последнее конечно влияет на алгоритм, но не дает в итоговый набор нового решения, ИМНО.
Чтобы не было замкнутого цикла возможно поможет доп.условие

приложу часть VBA решения (без цикла по устранению неявных связей - руками можно 2-й раз прогнать код по новому диапазону) - и нюансы прописала в файле - продублирую здесь: (в качестве вывода для ТСа - хоть он и пропал как его связи)
- на более полном примере от Андрей VG - видны недочёты ТЗ:
(попробовала отказаться от рекурсии - встречала частый совет по возможности отказываться от неё)
- мой ВЫВОД:
ОСТАЛСЯ разрыв связи ЖЁЛТЫМ - т.к. клиент НЕ обязан вам сообщать о смене своих контактов... поэтому в такой непостоянной информированности о сторонних процессах (смена контактов клиента) -  всё равно могут появляться разрывы цепочек последовательностей…  
ОТСЛЕДИТЬ ??? ЗАЧЕМ ???? (тогда очередная пробежка макросом для устранения начальных неявных связей) - НО не будет успешна если нет этих неявных (или не отражены)
КОГДА СВЯЗИ НЕ ПРЕДОСТАВЛЯЮТСЯ - ВЫ ТЕРЯЕТЕ ТО. ЧТО НЕ ИМЕЕТЕ !!! (причина: система неполноценная ! - гнилой учёт того что считаете не надо вам)
ЕСЛИ НАДО: ВВОДИТЕ КЛЮЧИ…………… используйте связи по ключам !!
==============
я бы такие связи ТСа даже "многие-ко-многим" не назвала бы !! так что вы там теряете, ТС??  
==============
Андрей VG ещё раз спасибо за пример!
(может поэтому в рекурсии и застревало выстраивание дерева - потому что не продумана проверка результата?... но это отдельная история [хоть и небольшая] - но я тоже не проверяла итог на уникальность - ТС проверит если захочет по таким связям с обрывами и пустотами - по ним даже, полагаю, полноценный граф не описать [как уже указал выше Андрей VG ])

- вот это я и запомнила   ...
кстати класс для LIFO ...
да помню вариант ZVI: логика мне понравилась:Вообще очереди и стэки (если из простых элементов) - то сортировать в нужном порядке в рекордсете по какому-нибудь счётчику введённому (если есть возможность) - то как-то и проще...
смотрела вашу рекурсию xml, ходила вглубь по папке рекурсивно, даже в заполнение связанных комбобоксов (n-ое количество) - рекурсию вставить пришлось... но не люблю я это дело  и при случае  и возможности стараюсь отказываться от неё...
За напоминание о коде ZVI - спасибо... и за ваш имеющийся на форуме пример рекурсии xml - тоже спасибо!