I think that the Ground Control Pro is going to be the logjam in that MIDI routing. Hope that I'm wrong (I don't own it), but I don't see a way to merge the MIDI In stream with the GCP-generated messages transmitted to MIDI Out. Most MIDI devices stick to MIDI IN = receive, and MIDI Out = transmit., and these remain isolated from one another. MIDI THRU is an identical copy of what's coming to the MIDI IN jack.
But in some devices, you'll see a global "merge, soft-thru, in + out" or similar setting. That will serve the function of blending the MIDI In signal with the device's transmitted data, and sending it to MIDI Out. If it's not part of a device's feature set, then the alternative is an external MIDI Merge or MIDI Thru box. Sometimes, a little creative MIDI routing (to a box that already has MIDI In / Out / Thru jacks) and some compromise will substitute for that.
Of course, "soft-thru" jacks can be problematic, too; as you'll have to pay closer attention to MIDI channels, Omni On/Off, assigned controllers, etc. I believe that you could jumper the In & Out jacks directly together in the Eclipse. (I'm not sure what the advantage would be). Some MIDI devices perform their diagnostics routines in the same way. But I noticed that SEQ OUT parameter in the manual, and I'd suggest keeping that one OFF.
I don't know that MIDI feedback would be possible if three / four 'Factors (only) were all looped MIDI Out to MIDI In. If any one of them had OUTPUT set to XMT, then that 'Factor wouldn't pass MIDI on though. If all of them have OUTPUT = THRU, then … no MIDI is being generated within the loop. It's when you add a 'rogue' device to the chain (one that merges MIDI Out + MIDI In / Thru) that the feedback loop is completed. It's transmitting MIDI data, and that same data has the potential to come back through it's own MIDI In jack.
