I'm back with more info.
The "nvidia" and "nv" drivers are fully functional again on my MacBook Pro 17". I'm not exactly sure what I did which changed things, but I have an idea. Last night while using OS X, I had my Dell 2405FPW plugged into the DVI port and was using a dual-monitor config with the Dell and the built-in display, using an external USB keyboard. At one point I closed the built-in display. The machine went to sleep, and then I woke it back up using the external keyboard while keeping the display closed, so at this point I was only using the external display.
This morning, I opened the built-in display. OS X didn't re-activate it (not sure if this is normal behavior or a bug), so I rebooted. On a lark, I decided to boot into GNU/Linux, and sure enough, the "nv" driver came up on mirrored on both displays. I shut down gdm, restarted with the "nvidia" driver and it's working perfectly now, too.
I seem to recall using only the external display with OS X just before I got the GNU/Linux drivers working last time, so that might be the thing which triggers it. I'll experiment later tonight, but right now I'm too busy trying to get actual work done now that I have working video in GNU/Linux
I've rebooted several times, but haven't booted OS X yet, since that's when my troubles started last time I had a working driver. I've tried two different kernels, Debian unstable's latest 2.6.21-4-amd64, and my own, which is based on Debian's 2.6.21-4 source, except I've applied the mactel patches and I created my own MacBook Pro-specific config file. Both kernels work fine with the "nvidia" driver (haven't tried "nv" since that first reboot). I also upgraded the libc and X packages to the latest Debian unstable versions with no problems, so I don't think they're what caused things to stop working last time (see my previous message a couple of posts back).
Here's another bug report. Compared to the report I generated after the driver stopped working the first time, the only differences which stand out for me are these (non-working config is "<", working config is ">"):
< 16: 953 0 IO-APIC-fasteoi uhci_hcd:usb4, uhci_hcd:usb5, nvidia
> 16: 1843 0 IO-APIC-fasteoi uhci_hcd:usb2, uhci_hcd:usb3, nvidia
(sharing interrupts with a different USB controller)
< Expansion ROM at d3000000 [disabled] [size=128K]
> [virtual] Expansion ROM at d3000000 [disabled] [size=128K]
(ROM mapping is virtual in the working case? I'm not sure what lspci means here.)
< 30: 00 00 00 d3 60 00 00 00 00 00 00 00 0b 01 00 00
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 00 00
(a line from the lspci dump; I have no idea what it means)
These diffs are consistent with the bug report I generated the first time I had a working driver, i.e., the two working reports are identical with regard to these 3 lines.
zander, do you know what is the significance of the two lspci diffs?