Почему Rust не меняет порядок полей в перечислении для размещения в памяти?

Я знаю, что поля в структурах Rust автоматически переупорядочиваются для экономии памяти (если, например, не указан #[repr(C)]).

Я предполагал, что то же самое верно и для перечислений. Сегодня я создавал простой вспомогательный тип (семантика примера не имеет значения, речь идет о расположении памяти):

pub enum LazyRwLockGuardVersionA<'a, T> {
    Unlocked(&'a RwLock<T>),
    Read {
        lock: &'a RwLock<T>, // still neccessary for promoting to write lock
        guard: RwLockReadGuard<'a, T>,
    },
    Write(RwLockWriteGuard<'a, T>),
}

В то время как необработанная защита чтения/записи использует 16 байт, этот тип использует 32. Чтобы заставить компилятор использовать оптимизацию ниши, я попробовал эту версию:

pub enum LazyRwLockWriteGuard<'a, T> {
    Unlocked(&'a RwLock<T>),
    Write(RwLockWriteGuard<'a, T>),
}

pub enum LazyRwLockGuardVersionB<'a, T> {
    Read {
        guard: RwLockReadGuard<'a, T>,
        lock: &'a RwLock<T>,
    },    
    NonRead(LazyRwLockWriteGuard<'a, T>),
}

Это успешно снижает использование памяти до 24 байт.

Однако я заметил кое-что странное: При изменении порядка полей в варианте Read:

pub enum LazyRwLockGuardVersionC<'a, T> {
    Read {
        lock: &'a RwLock<T>, // order of fields reversed
        guard: RwLockReadGuard<'a, T>,
    },
    NonRead(LazyRwLockWriteGuard<'a, T>),
}

Этот тип внезапно снова использует 32 байта.

Моя версия Rust — 1.77, вот репродукция Godbolt: https://godbolt.org/z/svE5v6Tr8

• Разве спецификация не позволяет переупорядочивать поля перечислений, или компилятор здесь просто «ленив»?
• Есть ли примерное представление об алгоритме, который в настоящее время использует компилятор? для макетирования перечислений, чтобы я мог понять этот результат и предотвратить случайную пессимизацию моего кода в будущем?