Поток данных (библиотека параллельных задач) и асинхронное ожидание

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

Если вы используете ActionBlock с async action, не устанавливайте его MaxDegreeOfParallelism (что означает, что используется значение по умолчанию 1) и не связывайте его с BufferBlock, тогда action будет выполняться для одного сообщения за раз, параллелизма не будет .

Если вы обрабатываете сообщения вручную, используя такой цикл:

while (await bufferBlock.OutputAvailableAsync())
{
    var message = await bufferBlock.ReceiveAsync();
    await ProcessMessageAsync(message);
}

Тогда сообщения будут обрабатываться тоже по одному.

Но в обоих случаях это не означает, что сообщение будет обрабатываться одним потоком. Он может обрабатываться несколькими потоками, но не параллельно. Это связано с тем, что после await выполнение может возобновиться в потоке, отличном от того, в котором оно было приостановлено.

Если вы используете какой-либо другой способ обработки сообщений (например, используя описанный выше цикл, но пропуская await перед ProcessMessageAsync()), тогда несколько сообщений могут обрабатываться одновременно.

Вы неправильно понимаете, что делает await. Он ничего не разветвляет, он просто ожидает результата уже асинхронной операции.

Методы, отмеченные ключевым словом async, не становятся автоматически асинхронными. Только когда внутри метода async встречается асинхронная операция, выполнение продолжается асинхронно. Ключевое слово async просто сообщает компилятору, где должно продолжаться выполнение после завершения асинхронной операции.

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