Отличные вопросы, не такие уж и ламерские, с этими моментами многие сталкиваются. Давай разберемся.

1) Порядок исполнения цикла for

Стандартное поведение:

Цикл for i := StartValue to EndValue do ... всегда исполняется от меньшего к большему (по возрастанию). i будет последовательно принимать значения StartValue, StartValue + 1, …, EndValue.
Цикл for i := StartValue downto EndValue do ... всегда исполняется от большего к меньшему (по убыванию). i будет последовательно принимать значения StartValue, StartValue - 1, …, EndValue.
Гипотеза про оптимизацию (от большего к меньшему): Твоя гипотеза о том, что for ... to ... для экономии исполняется от большего к меньшему, неверна. Семантика языка Delphi четко определяет порядок итераций: to - возрастание, downto - убывание. Компилятор обязан следовать этому порядку.

Возможные причины “неожиданного” поведения:

Изменение счетчика внутри цикла: Если ты пытаешься изменить значение переменной-счетчика (i в примерах выше) внутри тела цикла for, это может привести к непредсказуемому поведению (хотя компилятор Delphi часто защищает от прямого присваивания счетчику). Делать так категорически не рекомендуется.
Изменение границ цикла внутри цикла: Значения StartValue и EndValue вычисляются один раз перед началом цикла. Их изменение внутри цикла не повлияет на количество итераций текущего цикла.
Побочные эффекты в теле цикла: Возможно, код внутри цикла делает что-то, что влияет на данные, которые ты анализируешь, и создает иллюзию неправильного порядка. Например, если ты удаляешь элементы из списка, по которому идешь циклом for ... to ..., то пропустишь элементы. В таких случаях часто правильнее использовать for ... downto ... или цикл while.
Неправильное понимание логики: Возможно, ошибка не в порядке цикла, а в логике кода внутри него или в ожиданиях от результата. “Неверный результат” часто бывает следствием ошибки в алгоритме.
Использование for in: Если ты используешь цикл for element in Collection do ..., порядок итерации зависит от типа Collection. Для массивов, строк, списков (TList, TStringList) порядок обычно соответствует индексам (от 0 к Count-1), но для других коллекций (например, словарей) порядок может быть не гарантирован без явной сортировки.
Настраивается ли порядок? Нет, сам порядок (to - вверх, downto - вниз) не настраивается. Ты просто выбираешь нужный тебе вариант (to или downto) при написании кода.

Если результат не соответствует ожиданиям, скорее всего, проблема в логике кода внутри цикла или в том, как ты взаимодействуешь с данными. Попробуй отладить код по шагам и посмотреть, как меняются значения переменных.

2) absolute в описании типа и синтаксис case ... of

absolute: Это ключевое слово используется для объявления переменной, которая располагается по тому же адресу в памяти, что и другая переменная (или по конкретному адресу, что используется редко и в основном для доступа к аппаратуре).

Пример: var A: Integer; B: Integer absolute A; Здесь B — это просто другое имя для той же области памяти, где хранится A. Изменение A изменит B, и наоборот.
Почему не работает в type? absolute работает с переменными (экземплярами данных в памяти), а не с описанием структуры типа. Внутри type TMyRecord = record ... end; ты описываешь шаблон, по которому будут создаваться переменные, а не сами переменные. Ты не можешь сказать, что одно поле типа должно находиться по адресу другого поля типа — это лишено смысла на этапе описания шаблона.
Синтаксис case ... of внутри record: То, что ты описал (case Byte of 0: (...); 1: (...); или case Char of 'a': (...); 'b': (...);), — это определение вариантной части записи (variant record).

Зачем это нужно? Это способ позволить разным полям разделять одну и ту же область памяти внутри структуры записи. Это похоже на union в языке C/C++. Ты говоришь компилятору: “вот эта часть памяти может интерпретироваться либо как набор полей варианта 1, либо как набор полей варианта 2, и т.д.”. Все варианты начинаются с одного и того же смещения внутри записи и перекрывают друг друга. Размер вариантной части определяется самым большим вариантом.
Пример:
type
  TDataKind = (dkNumber, dkText); // Перечисление для обозначения типа данных

  TMyVariantRecord = record
    FixedPart: Integer; // Обычное поле
    case Kind: TDataKind of // Поле-признак (tag field) и его тип
      dkNumber: (NumberValue: Double); // Вариант 1
      dkText:   (TextValue: string[20]); // Вариант 2
  end;

// Пример использования:
var
  MyRec: TMyVariantRecord;
begin
  MyRec.FixedPart := 10;
  MyRec.Kind := dkNumber; // Указываем, что сейчас там число
  MyRec.NumberValue := 3.14;
  // В этот момент обращение к MyRec.TextValue будет некорректным

  MyRec.Kind := dkText; // Указываем, что сейчас там текст
  MyRec.TextValue := 'Hello';
  // В этот момент обращение к MyRec.NumberValue будет некорректным
end;
Бестеговые (tagless) вариантные записи: Можно опустить имя поля-признака (Kind в примере выше), но тип (TDataKind, Byte, Char, Boolean и т.д.) все равно нужен:
type
  TAnotherVariantRec = record
    case Boolean of // Тип есть, имени поля-признака нет
      False: (IntValue: Integer);
      True:  (PtrValue: Pointer);
  end;
В этом случае программист сам отвечает за то, чтобы знать, какой вариант сейчас используется. Это менее безопасно, но иногда нужно для прямого отображения структур данных из других языков или форматов.
Зачем нужен тип (Byte, Char, TDataKind) в case?
Определение меток: Тип определяет, какие значения могут быть использованы в качестве меток (0, 1, 'a', 'b', dkNumber, dkText, False, True). Ты не можешь использовать метку, которая не соответствует указанному типу.
Структура и читаемость: Это часть синтаксиса, которая делает структуру определения ясной.
Поле-признак (Tag Field): Если ты указываешь имя поля-признака (Kind: TDataKind), то этот тип становится типом этого поля, которое реально хранится в записи и занимает место. Если имя опущено, поле-признак физически не создается, но тип все равно нужен для синтаксиса и определения меток вариантов.
Итог: Ты не можешь использовать absolute для наложения полей друг на друга внутри описания типа. Для этой цели в Delphi существует механизм вариантных записей (case ... of ... внутри record). Он позволяет разным наборам полей использовать одну и ту же память, а тип в case определяет возможные метки для этих вариантов (и тип поля-признака, если оно есть).