Насколько будет трудно выстроить большую систему, если выбрать определенную технологию, например .Net Framework ...

Такое характерно для крупных проектов на C++.
Ну, Chromium например. Там почти все разработано Google.

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

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

И Chromium собран из модулей, не все из которых написаны сугубо для него. Например, какая-то библиотека для XML, она написана Google под самые широкие нужды, а не под Chromium. Такого "модульного" мышления не хватает многим, кто не имеет вышеозначенного опыта.

Большие системы по определению сложные и на пути реализации могут быть подводные камни. Поэтому любой ответ будет предсказанием, которое реальной практике вообще не сможет соответствовать
Если технология не тянет, всегда есть выбор. Отказаться от той или иной фичи в задаче или искать обходные пути. Но сам принцип "стоять у одного прилавка" при нынешних возможностях выглядит туповато

Выстроить легко. Труднее выстроить так, чтобы оно само не рассыпалось. И еще труднее - чтобы не рассыпалось при воздействиях, таких как апдейты и использование дикими юзерами.

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

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