Разобрались, в чём дело: в быстром поиске синтаксис «поле:значение» по умолчанию ищет подстроку, и days_elapsed не исключение — число дней с последнего изменения сравнивается со значением как строка. Поэтому days_elapsed:10 находит все баги, у которых в числе дней встречается «10» (10, 100–109, 210, 1023, 6104…), а days_elapsed:1000 — только те, где встречается «1000».

Уже сейчас работают числовые операторы:
  days_elapsed<10   — изменялись за последние 10 дней
  days_elapsed>1000 — не менялись больше 1000 дней

Хотим починить поведение записи days_elapsed:N через двоеточие и выбираем семантику. Варианты:

1. «ровно N дней назад» (equals) — буквально то, что описано в справке, но на практике почти бесполезно;
2. «изменялись за последние N дней» (<=) — самый ходовой сценарий;
3. «не менялись дольше N дней» (>) — так в апстриме сделан похожий параметр owner_idle_time.

Какое поведение было бы удобнее для вашей задачи? Мы склоняемся к варианту 2, а точные диапазоны всегда можно задать операторами < и >.

> Какое поведение было бы удобнее для вашей задачи? 
Какой-то конкретной задачи нет, я смотрела на этой с т.з. пользователя, который хочет найти ошибки с фильтром по изменениям.  

>  «изменялись за последние N дней» (<=) — самый ходовой сценарий;
> Мы склоняемся к варианту 2, а точные диапазоны всегда можно задать операторами < и >.
Думаю, лучше так и сделать, просто дополнительно подправить справку для days_elapsed, чтобы она отражала реальное поведение.