I cut it because its an entirely different situation. In the pots/isdn example, you're taking two virtual serial ports, bonding them and providing an IP layer over the low-level bonded interface. In the current case, you've got two already-provided IP interfaces, and you need to bond them. It would only be analagous to the POTS example if you were doing this inside the wireless router, which happened to have two or more ADSL wan ports you planned to bond.
Interesting, but if you read the spec, you'll note that the WAN side must be a TAPI /serial device, not another IP network. Its wireless only on the lan side.
What is needed here is a way (in software) to bond two separate IP networks so as to present a single network to the client. I'm no expert but I'm not at all sure whether this could be done on a single machine - it would end up with three IP addresses, one for each incoming wireless network, and one for the resulting bonded one. I guess it would be possible to build routing tables to inform the OS which IP to direct traffic to, but this might be pretty complex. And then we're back to my original point
It's different because you're talking about bonding - which is not viable over 2 connections to 2 different ISP's (unless the OP and his neighbour use the same ISP, this is the situation he will be in) - as it requires the ISP's kit to (a) support it and (b) authorise it. The later is certainly not going to happen with your neighbour's account ;-)
What I'm talking about is load-balancing (or teaming as the software mentioned calls it) over two disparate connections. Bonding was standard in ISDN TA's/routers of the day, whilst the load-balancing was, and is, used to combine multiple POTS lines or when ISPs did not allow dual channel ML-PPP ISDN connections.
The software (proxy/router) presents one connection to the user, whilst the actual Internet connection uses multiple connections - this is the same with both POTS/ISDN and multiple IP interfaces. The only difference being that the latter is simpler as no modem/TA drivers are involved, just native IP interfaces. The front-end software, which is essentially what this thread is about, is the same.
The manual and configuration screens, appear to disagree with you. Most of the WAN connections documented are connected via standard NIC interfaces (e.g. DSL, Cable, etc.) - the same presentation that the software would see with a pair of WiFi NIC interfaces.
The mechanism is essentially the same for client presentation of two load-balanced POTS connections as it is for two load-balanced LAN/WAN connections.
The client only sees (and cares) about the one gateway address. The software proxy/router handles the rest. The "hardware" devices that do this are only called "hardware" devices because they are in a separate box. The software that they run is similar to the software required to do the lot on one machine.
The major difference between the two is the market. There are very few SOHO users who need to load-balance over two "broadband" connections on one machine. Hence, the solutions for this tend to be high priced, aimed at multi-user LANs and sold in separate boxes to justify the price. That does not negate the fact that the mechanics and the software are substantially similar for a single user on a single machine as for 1,000 users on a LAN.