Я не спец, но вот говорю.
Опыты по этой теме у меня не было времени проводить.
Один раз нужно было сделать форму с тремя почти одинаковыми табличными подформами. Мне лепить три одинаковые формы показалось лениво, и я сделал одну форму (табличную), которая кодом форматируется (в смысле, заголовки меняются, ширина и данные грузятся), а каждый SourceObject подчиненной формы ссылается на эту форму. Но тут гемор был в отлавливании событий этой "клонированной" формы, и , в общем и целом, мой вывод такой, что игра с динамическим интерфейсом не стоит свеч, поскольку с ним больше возни, чем проку.

Не стоит свеч в Access и в определенных случаях, я имел в виду.
Менять ширину/видимость колонок, к примеру, в отчете или что-то еще такое элементарное - в этом ничего опасного нет.

Подчиненная форма как контрол имеет всего 2 события - вход и выход, чего недостаточно. Я тоже по событию подчиненной вызывал процедуру в главной, но у меня была какая-то проблема, вроде бы главная не могла понять, откуда пришел вызов или что-то типа того.
Допускаю, что эту идею можно и нормально реализовать.

Рачаев Олег
Может я тебя и не совсем верно понял, прошу прощения за сумбур.
Меня вот второй вопрос заинтересовал про "связанные диалоговые формы". В моем "унаследованном" приложнии есть куча мест, где форма вызывает другую форму, дальше например, ждет что-то, спрашивает чего-то, далее в зависимости от результатов происходят те или иные чудеса - какие-либо операции с БД, либо еще какие-либо диалоги. Ты об этом в п.2 говорил?
При этом эти диалоги перемешаны с операциями действий с БД, что делает программу совершенно нечитаемой и неудобоваримой. Возникает вопрос, как это лучше всего упорядочить.
Есть шаблон MVC - модель-представление-контроллер. Насколько я понял, на основе его можно полностью разнести бизнес-логику, базу данных и представление. Пусть там окна хоть хороводы водят, но в этом участе кода не будет ни строчки из слоя БД или БЛ. Могу, наверное, переделать пример на эту тему из java на Access, видел в какой-то книге.