The descriptions of Messaging, the MessageHeader resource, and the $process-message operations all start with the affirmation that When a message is sent, there is a requirement for the response to be another message, e.g.

The destination application processes the request and returns one or more response messages [...]

Later on in the $process-message description, however, there is seemingly conflicting information about that requirement, presumably to reflect a different exchange pattern for asynchronous messaging (see description of the return parameter, and following text after the table).

Proposal to clarify how FHIR messaging is choreographed:

1. Change the return parameter cardinality of the $process-message operation to 1..1
2. In the messaging framework description, clarify the following text about asynchronous messaging by changing "In Asynchronous messaging, the server acknowledges receipt of the message immediately, and responds to the sender separately." to "In Asynchronous messaging, the server acknowledges receipt of the message immediately using a message bundle containing only a MessageHeader resource, and in cases of any errors, an OperationOutcome linked from MessageHeader.response. One or more application-level responses are sent to the originator separately (similar to the distinction of Communication Level and Application Level acknowledgments in HL7 v2.x enhanced mode ack processing)"
3. . Adjust the list of possible responses to the $process-message operation to reflect this clarificaiton.