Oшибка "circular unit reference" вот в таком коде:

Что делать?

Пропиши во всех модулях остальные модули в uses после implementation

Добавлено через 2 минуты и 26 секунд
Хотя нет, у тебя тут все сложнее. Проще все в один модуль запихнуть. А вообще тут изначально ошиюбка в иерархии классов.

В один модуль всё запихивать не хочу: слишком длинно будет.
А что посоветуете на счёт иерархии?

 Не правильно использовать в базовом классе параметры, у которых тип - дочерний класс. Другими словами, родитель ничего не должен знать о своих потомках. 

Согласен с Poseidon.
Я бы даже сказал что это недопустимо и ломает основополагающие принципы наследования.
Но в данном случае проблема не в этом.
Если Вы хотите использовать именно такую структуру unit-ов, то:
1. В BaseUnit TBase.owner объявить как TObject, в uses секции implementation добавить OwnerUnit а в коде использовать приведение к типу - TOwner(owner)
2. В OwnerUnit TOwner.a и TOwner.b объявить как TBase, в uses секции interface добавить BaseUnit а в коде использовать приведение к типу - TA(a) и TB(b) но лучше корректно спроектировать TBase и избежать этого

Этот ответ добавлен с нового Винграда - http://vingrad.com

Мне этого и не нужно. Мне нужно только, чтобы объект A  мог при необходимости обратиться к B и наоборот.

Вот наоборот быть не должно. Если А обращантся к В, то В считается родительским и он ничего не должен знать про А. Посмотри к примеру иерархию VCL. Там родительские классы не знают ничего про дочерние. Или еще пример: базовый класс в Delphi - TObject. Это красс-родитель для всех остальных классов и он ничего не знает не про одного своего потомка. Поэтому если у тебя появилась необходимость обратится из В к А, то надо что-то менять в логике программы.

Я бы хотел, чтобы А и В обращались друг к другу, находясь на одном уровне иерархии. Разве это недопустимо?

Что бы они общались на одном уровне иерархии, надо их обоих сделать потомками одного родителя, и все общие методы описать у родителя. Тогда не понадобится у A создавать параметры типа B, а у B - параметры типа А.

Это верно только если А наследуется от В а не обращается.

Не только допустимо но еще и является стандартной часто используемой практикой.
В Вашем случае есть 3 выхода из ситуации:
1. Классы обращающиеся друг к другу запихнуть в один юнит (самый простой, быстрый и удобный выход)
2. Использовать приведение к типу как я писал выше (наиболее часто используемый)
3. Ввести поддержку интерфейсов в этих классах и вынести их объявление в отдельный юнит (наиболее профессиональный подход но не всегда оправдывает затраченные время и силы)

Этот ответ добавлен с нового Винграда - http://vingrad.com

dnek, в данном случае на лицо не верно спроектированная иерархия классов. TBase, на сколько я понимаю, задумывался как базовый класс, коим он и является для TA и TB. В то же время TBase содержит в себе параметр типа TOwner. И все бы хорошо, но TOwner содержит парамеры типа TA и TB. Другими словами, из TBase мы вполне себе можем достучаться до TA (TBase.owner.a). Т.е. из родителя имеем доступ к потомку, а это в корне не правильно. Пихание в один юнит избавит от ругательств компилятора, но не избавит от дальнейших ошибок на уровне проектирования. В лучшем случае нарвемся на вечный цикл и, как следствие, мертвое зависание программы.

Да кто Вам сказал что это неправильно. Как пример - TControl.Parent и TComponent.Owner
Другое дело, что TOwner.a и TOwner.b корректнее было бы объявить как TBase и правильно спроектировать его, но TOwner может не знать о TBase но знать TA и TB. Да и TBase лучше объявить как abstract.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Нельзя объявлять только что-то типа "TBase.A: TA;". Это действительно недопустимо. Только "TBase.A: TBase;"

А с промежуточным классом, который не наследуется от TBase - сколько угодно и как угодно.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Ну хотя бы Стив Макконнелл в своей книге "Совершенный код" посвещает этому вопросу очень большое внимание. 

Возьмем хотя бы TControl. Базовый класс - TComponent. Возьмите реализацию TComponent, там нет ни намека на его потомка - TControl. Вы никак не выйдете из TComponent к TControl, кроме как прямым преобразованием. В нашем же случае с TBase можно легко выйти на потомка TA, а этого быть не должно.

К TOwner вообще нет притензий, тут все норально. Вопросы есть к TBase.

Теория и практика разные вещи
Посмотрите на объявление TControl и TWinControl в модуле Controls:


После этого, если хотите, продолжим дискуссию :)

Этот ответ добавлен с нового Винграда - http://vingrad.com