## Код:
```
MODULE Objects;
TYPE
  Object* = POINTER TO ABSTRACT RECORD
    facets-: Object (* кольцевой список связанных вместе граней мультиобъекта *)
  END;
 

MODULE Stores;
TYPE
   Store* = POINTER TO ABSTRACT RECORD (Obj.Object) END


MODULE BioModels;
TYPE
  Cell* = POINTER TO ABSTRACT RECORD (Obj.Object) END;
  (* Это кто-то из неизвестных биологов вводил свои типы для биомоделирования, но ничего не знал про Stores *)

MODULE BioModelsImpl;
  (* А тут нам надо реализовать Cell так, чтобы поддержать ещё и хранимость *)

TYPE
  Cell = POINTER TO RECORD (BioModels.Cell)
   .....
  END;
  
  CellStore = POINTER TO RECORD (Stores.Store) END;

   PROCEDURE NewCell* (): BioModels.Cell;
     VAR c: Cell;
        cs: CellStore;
   BEGIN
      NEW(c); NEW(cs);
      Objects.JoinFacets(c, cs);
  RETURN c
   END NewCell;

Использование:

  VAR c: BioModels.Cell;
  c := BioModelsImpl.New();
  ....
  wr.WriteStore(c.Facet(<id типа Stores.Stores>));

-- оставим тут в стороне вопрос, как мы удобно идентифицируем id типа.
У нас есть токены, например, - это будет постоянный глобальный объект-идентификатор.
В стандартном ББ модуль может иметь глобальной переменной один раз взятый Meta.Item от нужного типа.
```


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

Ну а для универсального применения: этот базовый Object должен тогда быть, как бы, неявным (обеспечиваться рантаймом).
Вы же не перепишете чужой абстрактный тип для наследования от своего базового Objects.
И тут вопрос: можно насчитать несколько кандидатов на функции такого базового Object. И это всё - доп. память, которая навязывается каждому объекту. Другой вариант - что сама реализация списка не кладётся в базовый Object. А только окончательный модуль реализации кладёт в свои объекты поле статического RECORD-типа Objects.FacetsImpl.