Столбец и так должен удалится.

Но поле с соотвествующим индексом останется в структуре хранения.

Соотвественно если тебе нужно убрать это лишнее поле открывай структуру хранения и удаляй поле оттуда

>>однако из XML способа хранения удаляемые свойства не удаляются.
>>Это обязательно удалять их из XML?

Есть путаница немного - способ хранения есть способ хранения - "XML" тут не причем - оно просто отображается так. Можно открыть через инспектор объектов - Alt-1 - далее Storage - далее - Data-Nodes.
Просто тот "XML" что отображается по "Вид->Просмотр способа хранения" гараздо удобнее для охвата структуры целиком.

Удалять или не удалять должно быть решено производсвенной необходимостью - ибо структура хранения по умолчанию это нечто вида:
Соответсвенно поля имеют в структуре соотвествующий номер (1,2,3) если вы удаляете например "Comment" и добавляете например "DateChange" то получите:
Если экспортить глобалами - то данные в 3-м индексе все равно остануться - имеено поэтому рекомедуют сначала занулить это поле у всей таблицы перед удалением.

Если вам не нравиться что при реальных 3-х полях у вас объект хранится в списке из 4-рех - то нужно удалить из структуры "Comment" и "DateChange" переставить на 3-й индекс - НО ! после этого нужно перекомпилировать все классы и программы где используются статические запросы по данной таблице (доступ то по полям) - и соотвественно обновить сам глобал (перенести данные из 4-го поля в 3-е) - потом индексы перестоить

Другое дело когда вы на уже созданной структуре хранения переименовываете поле "Comment" в "Reason" - в итоге вы все равно получите.
Вот тут совершенно точно имеет смысл удалить 4 -й узел, а 3-й перепривязать к Reason.
"Зависимые" классы и программы всё равно придеться перекомпилировать.

ЭКспорт в XML (как вариант выгрузки) по идее не должен захватить "фантомные" поля - но при импорте наличие "дырок" в структуре хранения всё равно будет обусловлено версией класса на системе куда производится импортирт.