No, it's OK. If you set an 'outbound-channel' on the endpoint you expect your Message will continue to trevel independently of it's reply channel in the Headers. But when your logic ends and you know by protocol you should return reply you just rely on 'reply channel' header and remove your last 'outbound-channel'.
This seems counterintuitive
You should look at this as encapsulation: imagine your Message was travel before through a lot of systems. Now you are getting it and should make some logic and in the end should return some reply. After some time it have been decided to improve logic of your system. So, it will be enough just to decouple your endpoints via additional 'outbound-channel'. But for calling system you're still a black box.
Now imagine what will happen if you will reply independently of 'outbound-channel': your reply-message will return just after first endpoint.
set different reply channels for different messages, but also *not* set a reply channel for some messages
In this case the first <bridge> relies *only* on reply-channel header. If there is no one, AbstractReplyProducingMessageHandler thorws ChannelResolutionException.
<bridge input-channel="someChannel" output-channel="defaultChannel"/>
Thanks to UnicastingDispatcher on the 'someChannel' and disabled loadBalancingStrategy failure of first handler (in our case first <bridge>) will dispatch the Message to the second <bridge>.
Is it what are you looking for?