OK. So it wasn't a problem with the clients themselves or the Dosbox IPX clients after all!
The issue in this case was that the UniPCemu handling of IPX echo requests was replying to it's own requests and causing a infinite storm of requests on itself (together with being unable to tell request from replies, which is another can of worms, replying to replies).
It also fixes the heavy loaded observed from UniPCemu's clients it seems, seeing as the connection speed is normal now! 😁
The second client sees the other client now, but immediately crashes when using the WinSock method (either displaying too many duplicates of the same player or crashing immediately once obtaining information about the game!).
MS-DOS multiplayer with Windows works now (with 2 clients, 3 not tested yet).
Edit: Started improving the UniPCemu loopback and host sending a bit. It now will send the packets to the host network always (except when forcing the host network for local IPv4 loopback). There's also some extra safety with IPX echo replies having a check on the Transport control needing to be 1 or less to trigger a reply to be automatically sent by the server (matching the Dosbox behaviour and causing the other side (used in Dosbox's ipxnet ping command and ipxgw/UniPCemu allocation of IPX node numbers (a simple collision test. If any client replies, it's assumed to be in-use and the next known unallocated node number is tried (and next etc.) until no collision occurs and the IPX node number is taken after a timeout of getting no reply for the request (nobody replying = not in use))). UniPCemu itself will increase (by 1) the Transport control field when receiving an IPX packet from anyone (indicating it went through a router). Then, when checking if to send a IPX echo reply (as Dosbox does), it will check if the Transport control field is less than 2 to trigger a reply back to the sender from the allocated node for broadcasted IPX echo packets (to the broadcast address, socket number 2), unless it's from it's own IPX node number (source address being itself). Once it sends a reply onto the host network, it's setting it's Transport control field to 1, making it act like it was sent through a router to be received already (and causing UniPCemu to not send another reply for it, fixing a race condition of sending the replies to replies, which shouldn't happen).
Edit: Just put a bugfix on ipxgw, to modify source networks when the specified network is non-zero. Thus sending packets from Dosbox to the correct network, instead of to network 0 always when sending from and to network 0(replacing the source with the network assigned to the client for proper receiving).
Edit: And fixed some more bug on ipxgw's side. There were some IPX header bugs with increasing of the wrong fields when receiving (counting it as through it went through a router). Although there's currently no limit on the amount of hops (it will increase each time it's received by a client (either UniPCemu or IPXGW)).
2 player multiplayer seems to run fine (1 Dosbox MS-DOS and 1 Windows 95 UniPCemu client), but whenever I add a second or third UniPCemu client, the MS-DOS client counts the clients connected, but never starts the game (anything past 1 Windows 9x client)?
Running Dosbox's "ipxnet ping" seems to give correct results as far as I can see, seeing the other UniPCemu clients as well as itself.
So the main issue is with more than 1 UniPCemu client. They can't seem to get past the synchronize phase? Perhaps it's not finding all clients for some weird reason?