sudo rm -rf /

Потому что Console.Write(ch);
В консоли всего один курсор => после всех переносов будет всё в одну строку писаться.

Потому что нигде в коде нет перевода строки

Схема вполне рабочая и такой стек применяется во многих компаниях.
Никаких проблем в C#, применительно к этой задаче я не вижу.

Anydesk, rdp

Chrome Remote Desktop. Мониторы нельзя раскидывать по разным окнам, но можно из бокового меню быстро между ними переключаться. У меня на работе 4 монитора, для меня из дома подключатся - самое удобное решение.
Нужна учетка Google.

Попробуй отечественный Getscreen, подключение через браузер, мониторы можно выбирать.

Всего 3 варианта:
- rebase
- merge
- cherry-pick
Последний скорей всего тебе не нужен.
А вот с первыми двумя настоятельно рекомендую разобраться. Что делают, чем отличаются и т.д. Они постоянно нужны для работы с гитом, и стоит потратить время на их изучение, вместо того, чтобы просто тыкаться наугад по ответам из интернета.

Ну хранить бинарные это в гитлабе - по мне не самая лучшая идея. Идеологически пакеты - это результаты а не исходный материал. Как один из вариантов - использовать внешнее хранилище. К примеру sonatype nexus. Притом он умеет и не только в .nuget. Бонусом - его умение полноценно поддерживать nuget-api. То есть не возникнет вопросов при использовании пакетов и восстановлении транзитивных зависимостей.
Конечно в .nuspec можно и нужно заполнять честно Видимо да, корнем будет Company или нечто подобное для группы компаний.
Дальше видимо отдельная ветвь нечто совсем общего для всех продуктов со своим ветвлением на lib/utils/helpers/etc и ветвления на продукты, где далее опять же нечто общее для всех версий и далее ветвление по версиям и дальше уже опять же modules/libs/utils

(кстати внутреннюю делёжку можно подсмотреть со стороны самой структуры дерева в nuget (рекомендуемая структура target от ms)

То бишь в итоге получится нечто типа такого:

Brand
 - CommonBrandSubTree
   - *
 - Subbrands
   - SubbrandsCommon
     - * 
     - ProductX 
       - ProductCommon
       - *
     - ProductY 
       - ProductCommon
       - *
________
* - это то самое lib/tools/frameworks/etc

Притом не стоит бояться слишком разветвлённого дерева - хотя на первом этапе это и будет выглядеть чрезмерно переинженеренным. Зато потом не придётся его ломать и ветвить на ходу.

Ну а смысл в общем-то есть: у среднего человека мгновенная память/восприятие способна охватить "за раз" 5-9 объектов и исходя из этого максимально комфортной структурой окажется дерево, где на каждом уровне будет видно где-то по 5-9 объектов.

Естественно волшебных гениев не существует и самую идеальную структуру не создать. Но можно посмотреть на те же имена от ms - где более-менее просматривается что-то подобное, но с итерациями к подходу (ветвление по платформам, архитектурам начали появляться попозже и т.п.)

с длиной имён путей/файлов - да можно огрести чуть дальше - на уровне сборки - win-раннеры не умеют в \\?\driveletter и воспользоваться вариантом длины пути в 32767 символов не выйдет...

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

Тут же можно за один проход по магазинам. Сначала пройдитесь по вашим комбинациям и сложите слова в хешмап "слово" -> список номеров пар, в которых оно есть.

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

Если же вы можете один раз что-то предподсчитать для всех магазинов, то потом можно выполнять "запросы" даже не проходясь по всем магазинам.

Можно по каждому тегу составить список магазинов, имеющих его в названии, упорядоченный как-то (допустим, по id магазинов). Эту структуру можно построить за один проход по всем магазинам и сохранить.

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

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

Конечно, есть. Можно увеличить скорость за счёт использования памяти.

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

Если подумать, можно ещё что-нибудь наоптимизировать. Но это уже надо знать больше нюансов конкретно вашей задачи.

с помошью рефлексии можно сделать много. но зачем?