Отображение панели Grid в режиме Grid.View = 3 - практически не управлемое. Этот режим был введен для совместимости с командой CHANGE. Прямого управления шириной столбца с заголовками и содержимым нет. Только опосредовано. Ширина заголовочной части кажется равна ширине самого широкого заголовка.

Лично я симулировал режим Change сделав обычный Grid с двумя столбцами и наполнял его "вручную".

Собственно, Вы сами расписали все сопутствующие проблемы. А теперь попробуйте также расписать зачем Вам вообще нужен режим Change? Не проще вывести поля таблиц вне Grid (например, справа) просто как TextBox, а в Grid оставить только пару ключевых полей для навигации? Ну, или на первой закладке PageFrame обычный Grid, а на второй - набор TextBox.

UAPЕсли в "опорной" таблице добавить (удалить) поле, то либо не появится соответствующий TextBox (либо возникнет ошибка).
Понятно, что можно написать программу, которая создаст в соответствующих координатах и размерах объекты на форме, но уж больно все это хлопотно.
Нетрудно понять, что технология Grid свободна от такой проблемы.

Добавление поля - это неизбежная модификация много чего, много где. И технология Grid вовсе не свободна от этой проблемы. Точнее, она, конечно, свободна, но только в крайне примитивных случаях, когда Вы ставите ColumnCount = -1. Как правило, такая ситуация встречается крайне редко. Обычно Grid требует некой предварительной настройки столбцов еще на уровне проектирования форм.

Так что, это не является каким-либо серьезным аргументом

Кстати замечу, что как правило, изменение структуры данных в процессе работы приложения не происходит. Как следствие, нет необходимости писать программу по динамическому созданию и размещению объектов на форме. Эти объекты просто кладутся в нужные места в дизайнере класса или формы еще до создания исполняемого кода (до создания EXE).

UAPЕсли в таблице очень много полей (не помещаются на экран), то удобно использовать Grid.View = 3 (или "симуляцию").
Таким образом, для навигации я использую Grid, а для корректировки Grid.View = 3

Экран монитора ограничен как по горизонтали, так и по вертикали. Поэтому как у Вас не умещается все в строку, точно также не будет умещаться и в столбец. Просто этот момент наступит чуть позже.

Как правило, большое количество полей объединяют на формах в некие группы полей близкие по смыслу. А если на форме мало места, то еще и на разные страницы PageFrame.

Кстати, если положить все объекты в контейнер и добавить ScroolBar, то получим полную симуляцияю Grid.View = 3

UAPПроблема в том, что Grid.View = 3 очень некрасивый и, как Вы заметили, неуправляемый.
Вот откуда мой вопрос.
Тут дело даже не в красоте, а в "не естесственной" навигации. Как Вы сможете внятно объяснить пользователями, что после последнего поля строки начинается первое поле новой строки? Переход между записями в таком режиме не очевиден для пользователя. Особенно, если полей действительно много.

UAPКак ни странно, я постоянно сталкиваюсь с задачами, где наборы полей в таблицах НЕСТАБИЛЬНЫ.
Здесь возможны несколько причины

1. Не продуманная структура базы данных или приложения
2. Не продуманное желание пользователя

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

Например, реквизиты компьютера. Для "правильной" структуры создается справочник названий реквизитов и дополнительная таблица значений реквизитов со ссылкой на этот справочник. В результате, добавление нового реквизита сводится к созданию новой записи.

UAPПоэтому изменения структур таблиц и прилегающие вопросы непосредственно ВО ВРЕМЯ работы программы меня очень интересуют.
Если изменение структуры таблицы снабдить хорошим контролем, то приличный пользователь вполне справится с корректировкой.
Так не бывает. Точнее, бывает, конечно, но для очень примитивных случаев, когда надо добавить, скажем, некий второстепенный реквизит вроде комментария. Если же добавляемое поле затрагивает взаимодействие нескольких таблиц, то, как минимум, нужен программный код, который это взаимодействие обеспечит.

Ну, например, захотел пользователь добавить в шапку документа поле, содержащее сумму строк этого же документа. Даже если пользователь сможет добавить это поле, то как он организует его наполнение? Только программированием.

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

UAPВ противном случае, придется программисту сидеть рядом и постоянно модифицировать структуры таблиц.
Зачем же доводить до абсурда. Модификация структуры данных при "правильно" спроектированном приложении, операция относительно редкая. Да, иногда требуется. Но не настолько часто, чтобы "сидеть рядом".