The way the ESB toolkit does is that the itinerary (and the state of execution of it) is attached to each message in a special context property. That’s how the various ESB components/pipelines/orchestrations know how to handle the message and what the next step in the itinerary is. If you change the itinerary definition, normally this will just be picked up by messages that arrive after that, not by running itineraries.
In your second example, however, you’re talking more about handling request/response, two-way scenarios, which are also supported by the ESB toolkit. In this case, you need to make sure that the two-way send ports use are using the right send/receive pipelines provided by the ESB toolkit, which use the ESB Itinerary Cache pipeline components so that when the response message is received, the itinerary state/definition left by the request message is attached to the response message so that it can continue to execute. That’s actually covered in the ESB toolkit docs, by the way.