when I did it it was on a single threaded version of cubase, so I didn’t encounter any thready issues. The algorithm was something like this:
each plugin had a parameter that the user could set to tell it which input pair it was feeding and another one for the output pair.
when the plugin recieved it’s processReplacing call it delivered its audio ins to the ‘master’ dll along with the current song time from the host and whatever its input/output parameters (mentioned above) were set to.
it then asked the master dll for it outputs, which it sent back to the host.
all processing was done in the master dll. this was able to tell from the current song time coming from each plugin, which order they were being called from the host. I had a switch which allowed you to choose between two different processing modes:
option 1) fast mode: assume that the ins and outs are coming in the right order and process them without any latency, or
option 2) safe mode: don’t assume anything about the order and use the inputs from the previous audio block to provide outputs for this audio block. obviously this introduces latency of 1 blocksize, but you should have all the data you need regardless of the order.
I suspect neither of these would work in Reaper, with it’s look-ahead processing etc. etc.
IMHO this sort of thing is a can of worms, but on the other hand, if it was easy everyone would be doing it, so don’t let that put you off.