We're probably at the point where I would have to tell you to go to actual support, but I'm pretty sure support is going to tell you that 7.5.2 is no longer supported.
If you want to try 10.1 and the newer 'IBM MQ Native' protocol then I can try to help with that.
First, let me make sure I understand your scenario, because I think I might be getting confused.
1. Receive a request on Request Queue, this request specifies a replyTo queue, but this replyTo queue is not actually used anywhere in the responses.
2. Send one response to Response Queue 1, ignoring the replyTo queue specified by the request.
3. Send a second response to Response Queue 2, ignoring the replyTo queue specified by the request.
Is that it? I feel like there's something I'm missing given how many issues you've been having.
You can set this up in 10.1 by adding a "channel" to the Respond step.
Note that this is a DevTest concept, and is *not related* to an IBM MQ server channel. In DevTest, a "channel" is just how a proxy queue and it's corresponding live queue are grouped together. A VSE recorder, or a VSE service running in pass-through mode, listens on the proxy side of a request channel and forwards requests to live side On the response side, it listens on the live response side of a response channel and forwards responses to the proxy side. I'd encourage you to read the documentation, which includes a diagram of what we mean by "Channel".
If you are not doing recording, and not doing pass-through, then the "Live" side of each channel is optional. The service just listens on the proxy side of a request channel and response to the proxy side of a response channel.
With this kind of channel in mind, you have to give each channel a different name so they can be differentiated. The name can be whatever you want; it's just a way to identify the channel. Like this:
Note that there is also an 'Ignore ReplyTo' option under each channel. You can tell the respond step to ignore the original request's replyTo on a per-channel basis. The 'disregardReplyTo' response meta-data property still works, but that disables replyTo on an individual response basis. The options in the Respond step apply globally to all responses sent over that channel.
The last thing you need is to tell DevTest which response channel to use for sending each response. This is done with a single meta-data property in each VSI response:
And the second response:
The 'channel.name' meta-data property must match the name of a channel given in the Respond step. With the IBM MQ Native protocol this is the only thing that matters when determining where to send the response. The rest of the connection and queue meta-data, if present, is purely for informational purposes.
If you are doing a recording, then you set up your multiple response channels in the recorder and the rest of this is automatically done for you. If you are building from RR pairs or from scratch then you have to make sure 'channel.name' is set correctly yourself, either with RR pair sidecar files or by editing the VSI manually.