Ну надо бы остальные статьи тоже почитать, а еще лучше лекцию послушать. Я тебе скидывал вроде.

Я правильно понимаю:
1. Запуск withContext(this.coroutineContext){ ... } - это ничего не дает, выполнение кода без такой обертки абсолютно идентично выполнению с такой оберткой.
2. launch и async в случае работы в одном потоке запустят джоб не сразу, а вероятно после следующей точки остановки? А вот если диспатчер многопоточный - то launch и async запустятся сразу, параллельно (ну если будет свободный тред)
4. Если надо дождаться корутины launch/async - используем join/await соответственно. Эти методы идентичны по смыслу, просто второй вернет результат
4.1. join/await - блокируют исполнение кода (suspend) но не поток.
4.2. Если 4 верно, то зачем тогда launch-join? Был бы async-await, ну вернет он Unit и чего?
5. runBlocking {  launch {  }  } - заблокирует поток то тех пор, пока launch не завершится. Т.к. внешний скоуп будет ждать всех дочерних. То есть это можно использовать для записи например в базу. В случае когда надо записать но данные потом не потребуются, можно использовать launch понимаю что если он завершится с ошибкой, то внешний try ее словит. Типа fire and forget но выполнения все же дождется.
6. withContext суспендит код пока не выполнит тело в другом контексте (вероятно обычно это используется для смены потока, для shared mutable state наверно. А для чего еще кроме смены потока?)

Я правильно понимаю:
1. Запуск withContext(this.coroutineContext){ ... } - это ничего не дает, выполнение кода без такой обертки абсолютно идентично выполнению с такой оберткой.
2. launch и async в случае работы в одном потоке запустят джоб не сразу, а вероятно после следующей точки остановки? А вот если диспатчер многопоточный - то launch и async запустятся сразу, параллельно (ну если будет свободный тред)
4. Если надо дождаться корутины launch/async - используем join/await соответственно. Эти методы идентичны по смыслу, просто второй вернет результат
4.1. join/await - блокируют исполнение кода (suspend) но не поток.
4.2. Если 4 верно, то зачем тогда launch-join? Был бы async-await, ну вернет он Unit и чего?
5. runBlocking {  launch {  }  } - заблокирует поток то тех пор, пока launch не завершится. Т.к. внешний скоуп будет ждать всех дочерних. То есть это можно использовать для записи например в базу. В случае когда надо записать но данные потом не потребуются, можно использовать launch понимаю что если он завершится с ошибкой, то внешний try ее словит. Типа fire and forget но выполнения все же дождется.
6. withContext суспендит код пока не выполнит тело в другом контексте (вероятно обычно это используется для смены потока, для shared mutable state наверно. А для чего еще кроме смены потока?)

2 - нет. Запустят они его сразу. Порядок выполнения зависит от диспатчера. Вообще, хороший вопрос, что будет выполняться сначала. То, что внутри launch или то, что сразу за ним, но это на самом деле не важно, потому что порядок сохраняется внутри одной корутины, а launch порождает новую

4.2 Зачем делать и то и то? Был бы Deferred, какая разница что он вернет Unit?

Я про один поток. Если все произошло в одном потоке. Что будет первым? Т.к. launch не suspended то я предположил что он не будет останавливать исполнение внешнего кода из-за корутины.

Ну потому что с точки зрения API так удобно. Меньше мест, где можно ошибиться

На какой середине?

Я про один поток. Если все произошло в одном потоке. Что будет первым? Т.к. launch не suspended то я предположил что он не будет останавливать исполнение внешнего кода из-за корутины.

Была бы путаница в API. Но, кстати, так было до structured сoncurrency в пре 1.0 времена: https://medium.com/@elizarov/structured-concurrency-722d765aa952

launch - фоновая работа, async - выполнить вычисления "паралельно" и дождаться их при вызове await.

Я думал единственное отличие в том, что async может вернуть результат. А остальное одинаково.

launch - фоновая работа, async - выполнить вычисления "паралельно" и дождаться их при вызове await.