Самая большая грабля - наличие id объектов в БД. Как правило - это TableID. Если TableId - относится к стандартной таблице (ну или к той, у которой на дев и ворк id совпадают) - то проблем нет. А вот если он относится к своей таблице (объекту), по которой id не совпадают - то получится, что восстановление копии БД на дев будет невозможным без потери логики.
Плюс - код таблицы (конкретное число) может встречаться еще на релейшнах. Т.е. при изменении кода таблицы - соотв слетят лукапы и прочие прелести релейшна.
А так - различие id объектов влияет только на синхронизацию. Но как сказал glibs - эта проблема решается через \Администрирование\Периодические операции\Администрирование SQL\Проверка\Проверка-Синхронизация.
По поводу версии Аксапты - скажу так. Независимо от версии (3.0, 4.0) проверка работает (со всеми снятыми галками), если до проверки потереть данные в табличке SQLDictionary (главное при этом не выходить из Аксапты), после чего запускать проверку.
Поэтому - если "программировать правильно" (с), mazzy, т.е. никогда не завязываться на код объекта (как следствие - никогда не использовать связку TableId, RecId) - то проблем не будет.
Однако, у вас может быть другая проблема, не связанная с id-шником. После переноса модификаций через XPO вы запускаете глобальную компиляцию?
Компилируя только свой проект - вы рискуете получить ошибку выполнения кода, если в системе имеется некомпилированный наследник модифицированного класса, (например, который не вошел в проект).
И еще есть грабли, связанные с разными id-шниками. Если вы занимаетесь поддержкой уже работающего приложения, то вам может быть удобно иметь построенные перекрестные ссылки на рабочей БД. Но строить их может быть удобнее не на рабочей БД (дабы не нагружать сервера). Соответственно, построить ссылки на копии рабочей с последующим переносом таблиц XRef* на рабочую у вас не получится