ArXen42

Уже в общем-то даны подробные ответы, мне по этому вопросу когда-то запомнилось следующее утверждение:

• Интерфейс описывает, что объект может сделать.
  
• Абстрактный класс описывает, чем объект является.
  

Пространства имен это по сути просто синтаксический сахар (ну и немного метаданных вроде), для .net это просто префиксы имен типов. Т.е. то, что выглядит как MyClass, находящийся в пространстве имен MyNamespace, для CLR является типом с именем MyNamespace.MyClass, поэтому MyNamespace.MyClass может быть в одной сборке, а MyNamespace.AnotherClass в другой.

Это value type, там особого оверхеда на память нет, насколько я знаю, т.е. Int32 свои честные 32 бита и будет занимать. Об этом можно почитать в CLR via C# или вот статья, например:
https://habrahabr.ru/post/136609/

Сами по себе методы ничего не занимают, но любой объект (reference type) содержит ссылку на MethodTable, размещенный единожды (см статью).

Можно попробовать сделать data типом Object, но не факт, что рантайм сериализация это дело подхватит. И потом работать с ним в стиле if (data.GetType.IsArray) ... (ужас какой).
Но, как мне кажется, это плохой подход. Если приходят разные данные - нужно и сущности разные делать. Хотя, конечно, зависит от контекста задачи и т.д.

Делал не так давно задание по стеку на массиве, получилось более менее прилично вроде (можно без особых проблем реализацию IEnumerable прикрутить). Код. По заданию требовалось сделать это дело на VB.Net, хоть и писал на С#, исходников не сохранилось, но особой разницы и нет.
Еще рекомендую заглянуть на MS/Mono реализацию стека, там по сути тоже самое, но более навороченное.

Можно занести результат Interselect в словарь элемент - количество вхождений, потом пробежаться в цикле по листам, подсчитывая конкретное количество. Что-нибудь вроде

var lst1 = new List<string>(){"1", "2", "3"};
		var lst2 = new List<string>(){"4", "2", "3"};

		var intersect = new List<String>(lst1.Intersect(lst2));
		var res = new Dictionary<String, Int32>();
		intersect.ForEach(el => res.Add(el,0));

		foreach (var el in lst1)
			if (res.ContainsKey(el))
				res[el]++;
		foreach (var el in lst2)
			if (res.ContainsKey(el))
				res[el]++;


		foreach (var el in res)
			Console.WriteLine("{0}: {1} раз(а)", el.Key, el.Value);

Модификаторы доступа несут скорее информационную функцию, чем защитную. От кривых рук все равно ничто не защитит. Они помогают быстро понять структуру класса, роли его членов и структурировать код.

Может оказаться полезным посмотреть устройство редактора крафтов в Kerbal Space Program. Там он толково сделан (по крайней мере процесс соединения деталей). Там и радиальное крепление, и по определенным точкам (на "ноды").

Возможно вам поможет описание моей игры - тоже новичок, но делаю уже более полугода, общая архитектура более менее устаканилась. Суть игры вдохновлена Космическими Рейнджерами - вселенная, состоящая из звезд, основное место действия - звездные системы, игра протекает внутри них. Соответственно до старта игры ни одного объекта практически и нет - только пустышки и скрипты на них, ну и UI. При старте игры из сохранения (либо случайно генерируется) вселенная - массив звезд, которые в свою очередь содержат планеты, пояса и т.д. Эти данные никак не связаны с MonoBehaviour, просто статический массив (List на самом деле, но не суть). При старте игры опять же из сохранения берется местоположение игрока, информация о его корабле и в соответствии с этим
1)Спаунится текущая система: солнце, планеты (есть префаб планеты, при спауне висящий на нем скрипт накладывает случайно генерируемую текстуру, а другой скрипт размещает в пространстве в соответствии с заданными параметрами орбиты) и т.д.
2)Спаунится игрок (а в будущем и другие игроки)
Таким образом сцена содержит только пустышку игрока с повешенными на него скриптами и объекты UI. Все остальное создается по ходу игры.