BiTel

То есть получается, что для каждого случая будет какой-то свой приоритет у статусов фиксированный, жёстко прописанный в конфигах. В бд он в смысле не сохраняется для каждого установленного промежутка...

Не то. Вопрос не в том, какой статус каким может перетираться. Любой может перетираться любым, если речь идёт об установке статуса из клиента BG. Если же статус изменяется каким-нибудь автоматическим процессом, то логика усложняется - какие-то статусы в будущем иногда нужно оставлять нетронутыми. Это зависит от логики самого процесса и специфики оператора. Поэтому и предлагаю для каждого процесса, меняющего статус, хранить свой конфиг.

Хм, ну да - выходит так..

Хорошо ..Но в идеале отключить автоматику - это значит , что вообще ничего не делаем. Т.е меняете статус сегодня ..и СЕГОДНЯ и ТОЛЬКО сегодня он меняется. А завтра и тп он остаётся старым ..вдумайтесь в это ..вы хотите этого ?
Пример:
с01.07.2010 - 10.07.2010 - активен
11.07.2010 - 20.07.2010 - приостанолвлен
с 21.07.2010 - активен

И тут его закрывает по балансу 6-го числа .. Становится так

с 01.07.2010 - 05.07.2010 - активен
с 06.07.2010 - 06.07.2010 - закрыт
с 07.07.2010 - 10.07.2010 - актвивен // внимание - ( вы точно этого хотите ??? ) .мы же не меняем статус в будущем или как ? или все-таки меняем ?
11.07.2010 - 20.07.2010 - приостановлен
с 21.07.2010 - активен //а тут вы точно уверены ?

Или вы хотите так ?
с 01.07.2010 - 05.07.2010 - активен
с 06.07.2010 - 10.07.2010 - закрыт
11.07.2010 - 20.07.2010 - приостановлен
с 21.07.2010 - активен //мне этоn вариант тоже не нравится

Покажите на это конкретном примере .как работает ваша отключаемая автоматика ? а то я додумываю, додумываю . А вы сами может сами на этом конкретном примере
показать как должна отработать "отключаемая автоматика "? я пока не могу понять что вы хотите . вот helpdesk -е нам точно сказали, хотим чтобы статусы приостановлен не перетирались , остальное перетиралось .Это и реализуем .. ждем более внятного объяснения от вас

То есть кому то приспичило изменить старый алгоритм, а мы должны что-то доказывать?
Я привел вам реальную причину, которая может потребовать сохранить статус, каким бы "кривым" он не казался кому-то другому. Не верите в реальность - ваше право и ваша исходники. Перебирать все возможные сочетания статусов на их пригодность - у нас в организации нет Ванг, Нострадамусов, Глобов и прочих специалистов по гаданию на кофейной гуще.

так пока единый алгоритм усматривает вашим требованиям .просто его надо изменить

Так оставьте старый вариант и новый. На выбор. Указываешь в конфиге имя класса нужного алгоритма логики статуса - и полный консенсус между овцами и волками.

.... если мы новый статус накладываем сверху на неперетираемые промежутки, то что в итоге получается? Несколько кусочков новых статусов записывается, он же разбивается. А настоящий новый статус сокращается до последнего. Так вот, как должно выглядеть событие смены статуса? Для одного сокращённого кусочка из всех? Или для каждого? И событие после смены - аналогично. И как эти кусочки потому в событии найти? Статус у всех сменить в скрипте нереально ведь будет, если они разным событием придут. Или надо переделать событие, чтобы все кусочки пришли одновременно? Вот вы как используете события эти, например?