Среди Паскаль-производных языков понравилось решение в MSElang (разработчик известных в соответствующих кругах MSEgui/MSEide для Freepascal задумал свой вариант Паскаля, к сожалению, проект заглох со смертью автора):
https://gitlab.com/mseide-msegui/mselang/-/wikis/home/mselang_objects#variantpart
> -- Цитата:
> After regular fields there can be a variant part where the variant items share the same memory. Managed types like strings and dynamic arrays are not allowed in variant part.Examples:f2 and f4 are allocated at the same memory address.
Managed-тиы в вариантной части недопустимы, мол для "системных" нужд ограничение приемлемо. Встречаются альтернативные приёмы, например, Pointer Ownership Model:
https://resources.sei.cmu.edu/asset_files/whitepaper/2013_019_001_55008.pdf

Это политика "владения" указателями, в частности для С/С++ - статический анализ кода (с ограничениями) для верификации работы со ссылками в программе, где предусмотрены правила и для "объединений". Так по мотивам, упрощённо, к примеру, при записи данных в "вариантное" поле f4 у объекта типа objty (согласно выдержке выше) поля f2 и f3 должны считаться далее невалидными, если предшествовала какая-то работа с ними и их тип данных управляемый (соответственно, при потребности должна быть выполнена явная или неявная установка в null или финализация и т.п.).

Можно ещё глянуть в сторону AdaCore. В тех краях несколько лет назад было активное обсуждение потенциальной модели указателей для SPARK, без сборщика мусора с соответствующим уровнем безопасности и потенциалом для верификации, включая и поддержку вариантных типов-записей (статейка выше -- по наводке с тамошних форумов). Не в курсе, как дела обстоят на сегодня. У AdaCore кроме Ada/SPARK есть ещё и экспериментальный язык-платформа ParaSail, где, вроде бы, уже отработана модель "владеющих" указателей, но есть существенные ограничения (кроме "владеющих" нужны и иные, "не владеющие" указатели).
В общем, полезно покопаться в "адских кругах"...