Well now that we have some numbers, I can at least see why you would need multiple ISPs. Those are rather abysmal download speeds (and I suspect the upload side is no better). I'm not even impressed w/ the aggregated results.
Let’s talk about the static IPs. Having multiple static IPs is nice, but it’s hardly necessary, and in fact complicates management of the network in some respects. Obviously you need one for each WAN. But if you’re NATing all the devices behind the router, and then forwarding these static IPs to their respective devices and local IPs, I don’t see all that much benefit from them. The best case for using static IPs would be, for example, if you had two XBOX’es, and each needed to use the same port forwards on your router. That would introduce a conflict since you can only port forward to one internal/local IP address per static IP, and you can’t change the ports used by the XBOX. By adding another static IP, you get around that problem. Now each XBOX can be port forwarded independently.
So unless you have a situation like the XBOX, I recommend you ignore the fact you have multiple static IPs and simply work w/ the one static IP for each WAN, at least for now. Remember, the goal here is to start w/ the simplest configuration, and only add complexity when it’s absolutely necessary.
And let’s configure the router as ONE logical network (e.g., 192.168.1.x) and use the multiple WANs for load balancing and failover protection. I understand, it may not work exactly as you like, esp. w/ those lowly download speeds, but try it. Start simple, examine the results, and add complexity later as needed.
Do NOT configure any devices on the local network manually! That’s a maintenance headache. The ONLY time you should be doing that is when it’s an infrastructure device (secondary router, repeater, bridge, etc.). In all other cases, your devices should be using DHCP. If those devices need a *local* static IP (e.g., 192.168.1.100), use the router to associate its MAC address w/ that IP. And never use static IP assignments for any device that you have no intention of accessing directly. Always use the DHCP pool for those devices (e.g., iPad, iPhone, internet radio, VOIP adapter), anything where it serves no useful purpose to knows its IP address.
At this point you have a single local network, so all your sharing problems have disappeared. And all your devices are using DHCP, so there’s no need to manage individual devices. All your port forwarding is based on the two static IPs used by the WANs, and you only need to port forward those to the one local network.
Whether you want to somehow logically split up which WAN is used for remote access for various remote clients is up to you. But at least you do have some control how the bandwidth is allocated inbounds, if much less so outbounds. And your router will automatically keep track of which WAN to use for sending responses to those inbound clients.
That’s where I would start. Get that configured and then solve specific problems as they arise.
Since it's obvious this will become an issue, let's discuss it. One way to manage your limited bandwidth is w/ QoS (Quality of Service) controls. IOW, rather than use a coarse-grained approach where you attempt to dedicate this or that device to one or the other ISP, use the much finer grained controls of QoS to manipulate the *protocols*, *ip addresses*, *mac addresses*, etc., over the one logical network. So, for example, if Junior is creating havoc w/ the VOIP adapter due to all his downloading during the evening, rather than trying to keep him and the VOIP adapter on different ISPs, use the QoS feature to give the VOIP adapter higher priority! Don’t worry about which ISP is used. You have a sophisticated router, let it do the work for you. You’re just telling it what you want as an outcome (x is more important than y), let *it* figure out how to make it happen! If the router is sophisticated enough, you can probably control/change these settings according to the time of day, day of the week, etc.
That’s how you exploit this equipment. Let it do the work so you don’t have to. But that’s only going to happen if you configure it properly. As soon as you start trying to “man handle” the whole thing and over-think the solution, that’s when it starts to fall apart.
Now again, that doesn’t mean you won’t discover problems, weaknesses, things that need adjustments. But it’s a lot easier to move from the simpler to the complex, than the other way around. Address those issues as they arise.
P.S. Notice too, by using my approach, you've increased the reliability of the network. If one of the ISP connections is lost, your router will failover to the other ISP. Your network devices will be none the wiser, although you will obviously lose some bandwidth. Using your approach, if one of the ISP connections is lost, you lose that entire portion of the network!