Давайте зададим вопрос кто заказчик этой многопоточности?

Когда речь идет о серъезной оптимизации - то сначала смотрят в алгоритм. В его complexity.
Потом в язык программирования и компиллятор. И только когда все эти подходы исчерпаны - только
тогда подходят к параллелизму и concurrency.

Я лично категорически против введения этой фичи в VB/vba. Я не вижу в ней смысла.
Может смысл звучит так. - "Мы - бизнес и хотим чтобы наш код работал параллельно и конкурентно"

Я отказываюсь в это поверить. Бизнес такого никогда не заказывает. Он говорит обычно
так. Наш расчёт "X" работает медленно - нужно его ускорить. Далее зовётся программист
и он смотрит и говорит что можно сделать. В 99% случаев проблема решается просто
новым техническим заданием и переписыванием на однопоточный (!) C#.Net например
и на этом проблема будет закрыта.

Введение просто опций мультипоточности в VBA это заход "не с той стороны". Мультипоточность
это вообще самая крайняя и самая последняя мера. И ее избегают. Даже в ентерпрайзных
фреймворках она глубоко спрятана под капот (BigData Map/Reduce) где программист ее никогда
не делает явно. Он просто кодит мапперы-редьюсеры - по сути просто функции без состояний
а всё остальное делает биг-дата фреймворк. Тоесть даже в ентерпрайзе от мультипоточки долго
уходят и используют ее явно только в крайних случаях. И в общем там где болье IO/Networking.

В том что какой-то экономист или бухгалтер будет рисовать диаграммы с барьерами и программировать
критические секции и мьютексы я просто отказываюсь поверить. У меня волосы дыбом встают
когда я представляю что они там накодят и с КАКИМИ БАГАМИ они снова придут в этот
форум и какие вопросы они будут задавать. Они - классные ребята и хорошо знают своё дело
и мы их любим и уважаем. Но будем честны. Они спецом технические темы не изучали. Дай бох
им просто расчет смет и зарплат написать да так чтобы точность double не помешала или формат
даты всегда сошелся с шаблоном.

А вы говорите подвезли мультипоточность...