NoNameRОбщая схема БД сводится к классической Orders - OrderDetails. Но есть одно НО. Заказы, в течении своего времени жизни могут изменяться
Это никакое не НО. Иметь в системе заказы и не иметь возможности их корректировать, мягко говоря, не жизнеспособно. Так что именно по такой же схеме и реализуются корректировки заказов (заголовок-состав).

NoNameRСоответственно, каждое изменение заказа должно быть отображено в дереве
Я бы не был столь уверенным апологетом подобных "деревянных" конструкций. Чтобы собрать по заказу сводные данные (например, количество по каждой номенклатуре), необходимо, чтобы каждая корректировка заказа имела ссылку на исходный заказ, пусть даже формально она корректирует какую-то другую корректировку. В принципе, для расчета доступного остатка к исполнению заказа этого достаточно. У нас, например, нет связи между корректировками заказа. Если хотите - можете их сделать, но пользы от них немного, разве что блокировать разутверждение корректировки, если у нее есть дочерняя корректировка. Ну или Ваше любимое дерево нарисовать, если уж так все в него уперлось. Ибо заказ это такая полуабстрактная сущность, что в его корректировке может появиться вообще что угодно, если это допускается бизнесом. Итого, достаточно сделать связь (хоть ссылку в самой корректировке на заказ, хоть через дополнительную табличку - в рамках топика это не принципиально) между корректировкой заказа и родительским заказом, ее будет достаточно для расчета сводного заказа с учетом всех утвержденных корректировок.

NoNameRКлиенту нужно, чтобы в любой момент можно было просмотреть заказ, каким он был во время N-ной корректировки, если всего корректировок было M. В вашей схеме это можно реализовать, если я правильно её понял.
Можно. Это вопрос того, какие коректировки учитываются, а какие нет. Можно отсекать их по номеру, по дате, по моменту утверждения и т.п.

NoNameRНо теперь вопрос, который мне немного не ясен: какие именно данные хранить в корректировке? Только исправления?
Да.

NoNameRТогда как в ней отобразить, что такая-то позиция была удалена из заказа?
Отрицательным количеством.

NoNameRКак отражать изменение количества или цена на ту или иную позицию?
Либо двумя строками (первая удаляет позицию заказа, вторая создает новую), либо дополнительным признаком, что строка замещает строку заказа полностью.

NoNameRНеужели хранить в каждой из позиций ссылку на неё саму в исходном заказе?
Да. Связь по строкам также обязана быть.