I thought you would push your comment to the older thread, which is linked to the ticket. Anyway.
That's how i see this (i'm not a developer and don't know all XMPP specifications, but based on comments in previous discussion by developers like Guus or rcollier or there http://community.igniterealtime.org/thread/38398
ClientA sends a message to bare jid. Server receives it and checks if route.all-resources property is enabled. Otherwise it would use its internal logic to deliver the message (resource with most recent activity probably if there are a few connected resources with the same priority). When this property is enabled, it checks all connected resources, finds the highest priority and sends the message to all resources with this priority.
So, on the other side ClientB1 and ClietB2 receive that message. ClientB1 responds. I think that a client forms a packet which includes a full jid of ClientA, not a server manipulating the packet. Server delivers this response to ClientA. ClientA responds seeing that a resource of ClientB1 is in the packet, so it sends its respond to ClientB1 resource, not to a bare jid.
Server receives this message and sees that full jid is specified. By XMPP specifications server MUST deliver a message to a specified resource, not to all resources. So server omits the route.all-resources property in this case. I think this is intended and correct behavior, that's why the ticket has been closed with "Cannot Reproduce" resolution. Though maybe "Not a bug" resolution would fit better, but there is no such in the system.
Again, i'm not a developer, so not sure, but probably a client can be modified to always send messages (even replies) to bare jid, so then it should work with route.all-resources. Though i see not much use of only incoming messages syncing between resources. You would talk to someone on one client and then find all incoming messages on all other resources, but without your own replies. Probably a server can also be modified to not obey XMPP specifications. Maybe even a plugin would work, though it may need lower level interaction with server than a plugin can have. This is open source, so you can change the code or find someone to change it for you and create your own version of server or a client. But this will not be included as a core feature.