Процессор GPU выполняет так называемую векторно-конвейерную обработку. Это означает, что у него имеется набор конвейеров для векторов, то есть связанных между собой функциональных узлов, которые по очереди совершают однотипные операции над элементами массивов. Представьте себе конвейер на автомобильном заводе – на первом рабочем месте на шасси привинтили двигатель, потом конвейер подвинулся, стали там же прикручивать двигатель на следующее шасси, а на первое шасси в это время на втором рабочем месте устанавливают коробку передач, и т.д. Так же и в векторно-конвейерном процессоре. Он построен на том, что на каждом этапе конвейера выполняются одинаковые операции над разными элементами вектора. Компилятор разворачивает операции с массивами или простой цикл в такую конвейерную обработку. А если там будут условные операторы, всё сломается. Получится, что рабочий иногда должен монтировать двигатель, а иногда клетку с хомячком вместо него. Разброд и шатания, тем более, что эти операции могут быть разными по продолжительности. Конвейер так не работает. Поэтому условная операция будет вызывать очень длительную перенастройку контейнера на новую последовательность операций обработки.

Применимость тех или иных ГОСТов устанавливает заказчик. Ваш вариант вполне хорош. Главное, чтобы этот ГОСТ был упомянут в ТЗ. А само ТЗ тогда должно быть разработано по ГОСТ 34.602.

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

с одной особенностью ввиде того что можно создать несколько одинаковых по номеру переменных но с разным значение,но чтение/изменение видит только первую из них

Это размещение в памяти типа controlled, практиковалось в качестве возможного варианта в языке PL/I.