#spec
Что такое асинхронность/много-поточность с точки зрения официальной спецификации ECMAScript.

С точки зрения официальной спецификации - эти термины НИЧЕГО не обозначают.
И никогда не существовали.

Откуда растут ноги?
В далекие былинные времена (1997 год - 2015 год), спецификация языка ECMA была устроена таким образом, что взаимодействие JS кода, с JS кодом, например в другой вкладке, организовать было невозможно. По крайней мере, используя только возможности ECMA спецификации.

В целом вся, спецификация, была написана таким образом, что код, который исполняется одной из вкладок блокировал любой другой код любой другой вкладки браузера.

В силу этого опыта, появляется ряд докладов, о JS, где подобное поведение оправдывается его(JS) односторонностью.
С чем, в целом можно согласиться.

С 2017 года, когда официальная спецификация ECMA реформирует работу языка, декларируя термин Мульти - Агент, когда в спецификации появляется Atomics API - язык JS получает ту форму, которая позволяет HOST среде, так выстраивать исполнение JS кода, как ей (HOST) среде хочется. В том числе предоставляя API для всех возможных (паралельных )форм исполнения кода.

С 2015 года, когда официальная спецификация ECMA получила описание Promise, мы получили возможность от HOST среды в рамках списка задач - GenericJob и очереди задач PromiseJob - регламентировать процесс работы с JS кодом.



Что все это значит
До 2015 года, не существовало никаких механизмов в рамках спецификации ECMA, которые бы позволяли управлять потоком исполнения JS кода. Что, например, в том числе приводило к тому, что код одной влкдаки мог блокировать код другой вкладки.

Это поведение породило массу докладов, где авторы рассказывали о одно поточности JS языка, обосновывая это примерами из поведения выше. То есть маркирование JS как одно поточного языка.

С 2015 года, появляется официальный механизм управления выполнения кодом задач в ECMA, что автоматически приводит к тому, что тот же пример с вкладками перестает работать. стал ли JS много-поточным? (только потому, что соседние вклкдки перестали виснуть?)

С 2017 года, появляется API взаимодейтсвия (ATOMICS Api) для доступа к одной и той же области памяти.
С 2017 года появляется формализация процесса, который называется Claster Agent, который является абстракцией над процессом, кода любое католичество програмного кода, может взаимодействовать друг с другом, но при этом исполнеяется разным агентом.


Что из всего это следует
Язык JS, который регламентируется спецификацией ECMA, получил согласно спецификации, фозвомжность взаимодейтсвия разных блоков кода, между собой в условиях, когда они имеют доступ к одной и той же области памяти.

Язык JS - это язык, той формы абстракции, который не отвечает и не может отвечать на вопрос, КАК решается эта задача: многопоточно, асинхронно, мульти-процессами, вытесняющей многозадачностью и так далее.
Это язык, который предоставил с 2017 года, HOST среде, решать задачи в несколько Агентов, которые(агенты) могут взаимодействовать между собой на уровне абстрактного API, которое может быть реализовано как многопоточно, последовательно так и и любой другой форме которую придумают или реализуют на машинном уровне.

Это не задача JS - решать какая форма взаимодействия. Его задача была только в том, чтобы дать возможность HOST среде это сделать, что и появилось частично в 2015, и более полно с 2017 года.


Вместо ИГОГО
В былинные времена, язык JS был устроен таким образом, что он не позволял организовать вычисление разного кода, который бы мог между собой взаимодействовать.

С 2017 года, такая возможность появилась.

При этом сама спецификация - не диктует форму такой работы. Ее это не волнует. Она предоставляет только асбтракцию, которая позволяет взаимодействовать между собой таким блокам кода (Atomics Api)

То есть - утверждать в какой форме работает JS код (асинхронной, много-поточной или хуеточной) мы не можем, за исключением того, что HOST среда, может выбрать сама на основании тех возможностей которые предоставляет своременная спецификация, работать так, как ей удобно.