Нарушает ли доступ к массиву структуры POD как массиву ее единственного члена строгое сглаживание?

reinterpret_cast<int*>(textureHandles) определенно так же хорош, как &textureHandles->handle. В стандарте есть специальное исключение, унаследованное даже от C, в котором говорится, что указатель на структуру стандартного макета, соответствующим образом преобразованный, указывает на начальный член этой структуры и наоборот.

Использование этого для изменения ручки также прекрасно. Это не нарушает правил псевдонимов, потому что вы используете lvalue типа int для изменения подобъекта типа int.

Однако увеличение результирующего указателя и его использование для доступа к другим элементам в массиве из Texture объектов немного сомнительно. Джерри Коффин уже указывал, что возможно, что sizeof(Texture) > sizeof(int). Даже если sizeof(Texture) == sizeof(int), арифметика указателей определена только для указателей на массивы (где произвольный объект может рассматриваться как массив длины 1). У вас нигде нет массива int, поэтому сложение просто не определено.

Нет, это не гарантирует работу. В частности, компилятору разрешено вставлять заполнение после любого элемента структуры, но не разрешается вставлять заполнение между элементами массива.

Тем не менее, со структурой, состоящей только из одного элемента (типа int или чего-то не менее большого, например long), шансы на то, что большинство компиляторов не будут вставлять никаких отступов, довольно высоки, поэтому ваше текущее использование, вероятно, довольно безопасно, как правило.

Это, безусловно, нарушает строгое использование псевдонимов, и если функция может получить доступ к массиву как через int*, так и через Mesh* или Texture*, вы вполне можете столкнуться с проблемами (хотя, вероятно, только если она каким-то образом изменяет массив).

Судя по вашему описанию проблемы, я не думаю, что правила строгого псевдонима действительно то, что вас беспокоит. Настоящая проблема заключается в том, может ли компилятор добавлять отступы к структурам, которых нет в int, чтобы sizeof( Mesh ) > sizeof( int ). И хотя формально ответ положительный, я не могу представить себе компилятор, который делал бы это, по крайней мере сегодня, и по крайней мере с int или более крупными типами в struct. (Машина со словесным адресом, вероятно, добавила бы дополнение к struct, содержащему только char.)

Реальный вопрос, вероятно, больше в том, является ли общий код устаревшим и не может быть изменен или нет. В противном случае очевидным решением будет создание общего типа дескриптора:

struct Handle
{
    int handle;
};

а затем либо выведите из него свои типы, либо используйте reinterpret_cast, как вы предлагаете. Существует (или, по крайней мере, была) гарантия, позволяющая получить доступ к члену struct через указатель на другую структуру, если член и все предыдущие элементы были идентичными. Вот как вы имитируете наследование в C. И даже если бы гарантия была удалена, а единственная причина, по которой она когда-либо присутствовала в C++, заключалась в соображениях совместимости с C, ни один компилятор не осмелился бы нарушить ее, учитывая количество существующего программного обеспечения, которое зависит от нее. (Например, реализация Python. И практически все плагины Python, в том числе написанные на C++.)