Two "nat outside" statements, how?

You can have nat outside on as many interfaces as you want. No restricition there. Easiest way is to overload the interface on the backup with a floating static on it should the primary go down.

This will only work half-way. When the T1 link goes down, the NATs will correctly fail over to the ADSL backup link. However, when the T1 comes back up, the traffic will be routed back through the T1 but the translations set up for the ADSL link will not go away and will be used on the traffic going out the T1. Not what you want. It will also only work for failures where the T1 fails hard so the serial interface goes down.

You can hope that some day Cisco will consider this behavior of their NAT implementation a bug and fix it. In the meantime, there are some games you can play which may allow you to get around the limitations, but I have yet to convince a client they are worth trying out in production (the cost of developing and testing grossly exceed the savings possible for a onesey/twosey application).

Good luck and have fun!

I gotta disagree with the statement "It will also only work for failures where the T1 fails hard so the serial interface goes down."

With a primary route of 0.0.0.0 0.0.0.0 x.x.x.x using a /30 on the serial as

99% of internet circuits do -or- a primary route of 0.0.0.0 0.0.0.0 serial 0/0 no mater what happens with that circuit it will fail to the secondary. Doesn't matter if you loose protocol, physical or anything else as long as it goes down/down, up/down, or even down/up (screwy code) it will fail to the secondary route since the primary will be removed. You do not need anything to go hard down.

I do agree with you on the NAT's to a degree. The traffic could be a tad screwy while waiting for the timeouts, but thats not usually the case unless you are using unnumbered serials. When using IP'd serials the traffic will flow correctly and the NAT's will update themselves. You may have some sesions terminated and will definately loose state, but unless in an SSL type session they will simply rebuild.

You seem to have missed my point (or I'm not seeing yours). Routing works fine, as you say, no need for a hard failure. The problem is with the NATs for the old link which continue to be applied to traffic traversing the new link. The route maps or whatever used to determine what NAT to set up are only looked at when setting up a NAT, not when using an already existing NAT. The hard failure on the serial link is required to cause the NAT table to be cleared. If this behavior has changed (I have not checked it for awhile), then great. If not, the OP is in for a big surprise.