Strictly from a networking perspective, you cannot have conflicting subnets on the same network. If you were to have two nodes with IP 10.1.1.1 how would Solarwinds know which 10.1.1.1 you were talking about in a given instance? It would send the packet to gateway and gateway would look in routing table and can only have one place to send 10.1.1.1. In an advanced configuration you could have Solarwinds server with multiple NICs attached to different networks, but you would have same problem where server could only send it one place. Ultimately, you don't have a Solarwinds issue but a networking issue requiring a networking answer - which is NAT. You will need to choose which network to keep as-is and which one to NAT to different IP space. As per your last comment this function doesn't need to be performed by a firewall, just a router would do. Once you have NAT in your environment then that would solve your Solarwinds issue as well. Hope that makes sense!
We have built in logic where our software will state that the same IP address is already being managed. You would have to have different IPs for each system. You can use multiple NICs, I do this already, so you could in create a Management VLAN with management IPs for the systems that are the duplicate IPs.
Only the IP Address Manager has the capability to monitor Duplicate IP subnets, but this is because we are contacting the DHCP server for the data and not actually contacting the devices.
You can do this with additional polling engines -- one per zone with each APE has a network card in the 'zone', and another network card that can talk back to the main polling engine and central SQL server.
[you may have to play around with routing tables under windows to get this working perfectly]
you can have multiple nodes with the same IP address on different polling engines, and NPM will work properly on polling.
(I use this for pulling data from specific VRFS that is not in the common part of the MIB)
I have not tested if syslog and trap handling work correctly (i.e. if the trap reciver on an APE uses the API engine ID and the IP address pair correctly -- that would be a bug and support case if not)
Interesting thought! I guess as long as the SQL server isn't in one of the conflicting subnets, that would work! Great idea!