hvlad, дело не в PK. Первый пример так, для понимания что происходит. Есть составные индексы для поиска по дате, например. Из того, что я выяснил, получается, чтобы найти минимальную дату мне нужен индекс asc, а чтобы найти максимальную дату мне нужен индекс desc. Если используется конструкция between, то можно обойтись одним индексом. Но between не всегда нужен.
Но, честно говоря, не очень понятно, почему нельзя "переместиться" в конец "таблицы индекса" и прочитать предыдущую запись, которая, условно говоря, и будет максимальной?

Видимо, вот это:
авторПо сравнению с другими СУБД у индексов в Firebird есть еще одна особенность – сканирование индекса всегда однонаправленное, от меньших ключей к большим. Часто из-за этого индекс называют однонаправленным и говорят, что в его узле есть указатели только на следующий узел и нет указателя на предыдущий. На самом деле, проблема не в этом. Все структуры сервера Firebird спроектированы как свободные от взаимных блокировок (deadlock free), причем гарантируется минимальная возможная гранулярность блокировок, равная одной странице. Помимо этого, действует также правило "аккуратной" записи (careful write) страниц, служащее мгновенному восстановлению после сбоя. Проблема в двунаправленных индексах заключается в том, что они нарушают это правило при расщеплении страницы. На текущий момент неизвестен способ безблокировочной работы с двунаправленными указателями в случае, если одна из страниц должна быть записана строго перед другой.
Примечание. На самом деле, варианты обхода этой проблемы существуют и они сейчас обсуждаются разработчиками .
Данная особенность приводит к невозможности использования ASC-индекса для DESC-сортировки или вычисления MAX и наоборот, невозможности использования DESC-индекса для ASC-сортировки или вычисления MIN. Разумеется, сканированию индекса с целью поиска однонаправленность никак не мешает.
Радует, что: a) Разработчики знают об этой проблеме, б) Разработчики обсуждают варианты обхода проблемы. Будем надеяться на скорый результат.
Хорошо бы, конечно, вот такие узкие места отображать в руководстве по языку. Потому что у нас сплошь и рядом такая проблема, а проводить тщательный анализ производительности и потребности не было, да и ресурсов (Вот только когда пользователи поставили жёстко вопрос, мы начали шевелиться). Тем более, что в других СУБД всё по-другому.