The temporary Queue instance is technically created before the send operation still; it's just the MessageConsumer for that Queue that is created after the send now. Any insight into why RabbitMQ effectively creates the temporary queue on createConsumer there rather than on the actual createTemporaryQueue call? With ActiveMQ, the queue seems to exist in a stable form after createTemporaryQueue, with createConsumer then just starting delivery from the queue.

In any case, I'll revise this to differentiate between the useCorrelationId code path and the temporary queue path, performing the createConsumer call early in the latter case again (where we don't have to wait for a correlation/message id on the sent message). Let's track this in the derived issue: #36321