OK. After lots of debugging and checking the different results I finally found out why the collision detection wasn't working properly for the IP addresses.
The cause was pretty simple: when the client was authenticating in the simple text-mode tests I was doing (for quick verification), it was checking the current stage of the login process it was at.
It saw it was still at the protocol input stage (the final stage before DHCP(unimplemented) and the modes where it has been assigned an IP address. So when it checked the current stage against being in the Open state (which was simply to be past the protocol input stage or DHCP stage), it thought it wasn't parsing ARP yet (since the user wasn't authenticated with an IP address assigned yet).
So I then modified it to:
1. Handle the receiving of the ARP response (for collision detection) when still at the protocol stage, as long as it's already finished authenticating (a newly implemented finished substage which is used to perform the ARP lookups that are pending results from the network) and an ARP request is waiting for a response.
2. Keep the ARP to only give responses to requests when past the authentication phase and DHCP phases(DHCP being unused atm). So during the authenticating against the network itself to check for IP collisions, case 1 happens but case 2 doesn't(as the IP address isn't assigned yet, it's still scanning for usable addresses after all).
I also modified the pcap thread to also check other clients before discarding the incoming ARP packets. So if multiple clients respond to the same IP address, such a collision will also happen (although that shouldn't normally happen, as the checks before ARP is performed to determine a valid IP address already has checked against that and aborted the IP address validity check if it's already allocated on the same server).
So checks will only happen to validate IP addresses that aren't allocated by the server to also be free on other servers, if multiple packet servers are used on the same network.
Just ran 4 clients with the same packet server setting (although using different listen ports for the server to use of course).
Running them after each other, providing a login of the same range, IP address allocation accross the 4 servers work as intended: they will verify the IP addresses they haven't used in the account's IP address range against each other, counting the addresses as used if either they own it themselves or another client responds to the ARP request with a proper ARP reply.
So on the latest commits, you should be able to run the packet server with address ranging overlapping other devices in the network, provided they respond to ARP requests properly.
The next step, of course, is checking if the cheks with the PPP IPCP protocol run properly as well.
Although I can probably assume those run the same (it's using the same ARP mechanism after all, just at the packets stage (since it's in PPP mode, which requires it to be in the packets stage to run)).
Edit: OK. IP on PPP connects properly it looks like (on NT 4.0 workstation). Didn't try a second client yet though.
ipconfig does say the Default gateway is at the same address as the IP address assigned, but that might just be some oddity of the dial-up connection?