Наследование, композиция, агрегация

Что мне нужно, я как-нибудь разберусь. Но это же вы утверждаете, что ОО-языку необходимо наследование, вот я и спрашиваю: зачем?

Тогда не приводите JS в пример. Возьмем, значит, TS. Там множественное наследование есть? Вроде как не было.

Ну-ну, покажите как вы будете это делать. Вот представьте, что вы пишите аналог jquery на typescript и вам нужно добавить метод attr.

Ну и как это делать без интерфейсов, но с сохранением выбранной архитектуры (ядро + плагины)?

Это ваше «контролируется на уровне ОС» — это не проверка, по-вашему?

Overview of the Protected Mode Operation of the Intel Architecture
…
If we look back at the segment descriptor you will see information in the descriptor that relates to more than just its base address in memory (Figure 2 & Table 1). The additional information provided is primarily for the implementation of a protected system:
• How programs can access different types of segments,
• ensuring accesses within the limits of the segment (limit checking),
• maintaining privilege levels or who has access to a segment,
• and controlling access to privileged instructions.

Т.е. потребитель должен знать список всех возможных TypeID, а поставщик — не забывать его обновлять, а если не дай бог поведение поменялось, то отследить это можно только тестами?

Signatures are the part of a contract that can be checked and automatically enforced. Signatures are formed by adding constraints to types and other signatures. A constraint is a limitation on the use of or allowed operations on a value or location. Example constraints would be whether a location can be overwritten with a different value or whether a value can ever be changed.
All locations have signatures, as do all values.

Type safety and verification
Since types specify contracts, it is important to know whether a given implementation lives up to these contracts. An implementation that lives up to the enforceable part of the contract (the named signatures) is said
to be type-safe. An important part of the contract deals with restrictions on the visibility and accessibility of named items as well as the mapping of names to implementations and locations in memory.
Type-safe implementations only store values described by a type signature in a location that is assignment-compatible (§8.7) with the location signature of the location (see §8.6.1).
Type-safe implementations never apply an operation to a value that is not defined by the exact type of the value. Type-safe implementations only access locations that are both visible and accessible to them. In a type-safe implementation, the exact type of a value cannot change.
Verification is a mechanical process of examining an implementation and asserting that it is type-safe.
Verification is said to succeed if the process proves that an implementation is type-safe. Verification is said to fail if that process does not prove the type safety of an implementation. Verification is necessarily conservative:
it can report failure for a type-safe implementation, but it never reports success for an implementation that is not type-safe.
For example, most verification processes report implementations that do pointer-based arithmetic as failing verification, even if the implementation is, in fact, type-safe.