А как-же защита от дурака? И веское слово? Если вы не будете описывать систему словами, а только функциями, то у вас не получиться системного языка, а будет функциональный.
Примитивная защита от дурака будет, но полной защиты нет нигде. А в реальном мире тем более.
Однако типы систем хорошо классифицированы в известной литературе. Почему их не использовать?
Потому что они хорошо описаны для статической типизации, когда известно что черное это черное, а белое это белое.
Вот вы сейчас всю теорию систем превратили в туфтологию.
Ничего подобного. Почитайте как осуществляется построение систем человеком. Как строится модель предметной области? Кто определяет компоненты модели? Почему берется именно это свойство, а не какое-то другое (ведь модель никогда не рассматривает все свойства объекта)? Ответьте на эти вопросы.
И что мне теперь, что-бы проверить системы на подобность нужно тыкать палкой программиста?
Есть типы систем, но они не отражают суть системы. Это просто формальный параметр. Ну например, аналогия. Вот смотрите, Вы идете в магазин, чтобы купить пакет молока. Ну Вы же не проводите химический анализ каждого пакета молока, чтобы определить молоко перед Вами или не молоко. Вы просто читаете ценник и читаете упаковку. То же самое и тип систем. Вы можете проверять тип системы, но это не означает, что в пакет производитель налил молоко, а не, например, яблочный сок. Пока не вскроете пакет (не начнете взаимодействовать) определить сок там или молоко проблематично. Вы сразу увидели различие с привычным для Вас миром и тут же категорически выступили против, вместо того чтобы попытаться понять. Вам нужно больше читать про системный анализ. Тип объекта строго говоря не означает что перед нами действительно объект данного типа. Это означает что ожидается объект данного типа (и в 99 процентах это соответствует действительности). Поэтому работа с типами в обобщенном виде должна предусматривать такие несоответствия. Ну например, Вы купили пакет молока, а там дохлая мышь. Соответственно каши на молоке не получится. То есть Вы как программист должны это понимать.
И что мне теперь, что-бы проверить системы на подобность нужно тыкать палкой программиста? А я думал мы в современном автоматизированном мире живём, когда это можно сделать одной кнопкой.
Тип системы в данном случае просто строка. Вы можете читать и изменять его. Функции могут определять тип системы во время исполнения и предполагать, что работают с нужными системами. Вы должны понимать, что, во-первых, все динамично, во-вторых, практически все строгие системы типов имеют костыли для преобразования типов типа Variant в паскаль/делфи. Каждая промышленная система (Паскаль, С++, Ява и т.д.) предполагают махинации с типами, выходящими за рамки модели строгой типизации. Почему? Потому что в реальном мире невозможно предсказать что тип определяет объект. Можно это только предполагать. Например, Вы миллион раз видели ручку, знаете как ведет себя ручка и сразу можете определить что такое ручка. Но всегда существует ничтожный шанс, что перед вами окажется не ручка, а например стилус или автоматический карандаш или еще что-то, но не ручка.
Еще пример в программировании. Зачем нужен GUID? Ведь известно что за система и какой ее тип? А может быть неизвестно? А может быть поведение системы настолько сложно, что проще представлять ее как уникальную систему? Ответьте на эти вопросы. Казалось бы Микрософт породил интерфейс. Кому как ему не знать назначение данного интерфейса (класса и еще кучи всего)? Но нет, этого оказывается мало. Почему? Зачем интерфейсу еще и свое собственное клеймо бахать? Ведь в исходнике четко известно какой это интерфейс. Или неизвестно?
Бытовой уровень. Вода и лед. Всем ведь известно что тип лед это тип вода? Но когда речь идет обо льде (например гололедица) никто не думает и не говорит, что вода достигла такого агрегатного состояния, что ходить стало опасно. Проще представлять отдельный феномен - лед. Такая вот модель со своими свойствами. И даже когда я морожу воду в морозильнике для виски, я не думаю о воде, я думаю о кубиках льда, которые будут подаваться гостям. Хотя лед здесь нужен ровно для того, чтобы потом растаять и стать водой (ну и конечно впечатление от мероприятия 
). Никто ведь не предполагает - так переведу воду в другое состояния для придания других свойств, чтобы потом в спиртосодержащейся жидкости вернуть исходное состояние воды.
Все это живое отражение состояния систем и отношения к системам. Система вода. Состояние системы изменилось, и изменилось отношение к системе. Может быть настолько, что мы готовы рассматривать ее как иную систему. Почему и когда? Задумайтесь над этим. При этом мы применяем к ней иные методы (которые пригодны для льда, но не для воды в общем), но почему это происходит? Ведь вода будучи льдом осталось водой. Верно?
И еще по Вашим претензиям у меня к Вам встречный вопрос - вот Вы создаете сложный класс. А какой тип и вообще какие сведения определяют что входит в класс и почему это обычное целое 4-х байтовое число, а не 8-мибайтовое? Это прямо вот Ваша претензия иными словами. Кто решил, что для переменной цикла годится именно этот тип, а не другой? Почему Вы наследуетесь от этого класса, а не от какого-то другого? Ведь классов много и вероятность выбора одного из них крайне мала, почему именно он? Иными словами - кто решает что микроскопом можно забивать гвозди или нельзя? Тем более что микроскопом гвозди забивать можно?
