Не в упрёк, а в дополнение (юзеру выше). Всё таки не стоит сильно упрощать. Говоря про реализацию Option, Result и т.д., мы говорим про типы-суммы. В самом примитивном варианте, да, это будет реализована как показано у Анонима, где в случае отсутствия значения у нас не будет инициализирована память, но это хаки небезопасных языков, что не защищают свои абстракции. Да и с точки зрения типов это не Option-тип.

Для правильного "низкоуровневого" Option<T> нам нужен тег(is_some/is_none) и union(из двух вариантов T и Unit). Вполне рабочий вариант для языков с бедной системой типов, но не для чего-то вроде того же C++. Там всё несколько сложнее.

В Rust многие типы(из коробки core, std, alloc) идут как языковые features, то есть тот же Option не захардкожен в компилятор, но в реализации имеет метки для компилятора aka это вот именно Option, благодаря чему у компилятора больше контекста для всячиских оптимизаций. То же, например, с трейтом Drop. Тот же NonZeroI помечен как nonzero, если вы посмотрите исходники.

И возвращаясь к C++, то эмитировать алгебраические типы данных можно ещё и объектной системой, это "эталонный" способ для так называемых менстримных ООП языков. В C++ это всё очень нетривиально, но в базе своей подход строиться на том, что у нас есть базовый абстрактный класс(тип), а его наследники, реализующие его интерфейс - конструкторы.

Для примера код на Haskell:

data Option a = None | Some a

На волшебном ООП языке X:

abstract class Option<T>
class Some<T> : Option<T>
class None : Option<_>

На поиграться можете в Rust создать тип-произведение, один из элементов которого nonzero, и посмотреть, что в итоге sizeof вашего типа A и Option<A> будет одинаковый.