I don't want to go into the details of the particular problem that frustrated me, which is unlikely to be of benefit to many people, but I would rather like to draw a far more wide-ranging lesson from the methodology I used in attacking the problem.
At first I engaged in what is probably the best practice: I looked for the most obvious solution and made a quick fix. When the problem did not go away, however, I began trodding down the Path of the Fool: I began grasping after all the "unobvious" solutions and successively applying "quick fixes" with the hope that this awful error would just go away. Cut to five hours later. Nothing learned. And one very unhappy programmer.
So what's a pragmatic programmer to do when confronted by the Evils of Imponderable Internet Explorer Errors? Well, I've come up a with a new rule when it comes to these sorts of bugs. I am free to attempt the "quick fix" method for up to 30 minutes. But should any bug take longer than that to resolve, I must immediately turn to the Method of The Bulldozers. This is the debugging method that never fails.
Oh, you ask, but what is this wonderful method of which I speak? So good of you to enquire! The idea is simple:
1) Find the simplest test case that works. For example, prove that what you are attempting to do is possible in a simple, perfect world.
2) Make a backup of your web pages/code, or be very comfortable with your favorite editor's undo function (I'm a vim fan, and am usually foolhearty enough to proceed this way).
3) Add the test case to a completely stripped down version of your webpage and verify that it works. Also make sure that this test case does not work in the full version of your code. (If it does work in the full version of your code, slowly modify this test case in the direction of what you actually want, until it breaks. Then, optionally go on with step 4 if the same thing still does work in the stripped down environment and it's not stupidly obvious why it does only there.)
4) (The bulldozing part) Begin stripping anything and everything you can from the web page/program code that is causing you angst. Do this is binary chunks, for example, first rip out half the code, then the other half, and then perhaps the right 3/4 etc. In between each "tear-out," test to see if the problem has gone away. Usually, the problem is in one specific place, and you'll be able to zero in very quickly. Occasionally, there are two or more pieces of code in different locations conspiring to give you grief. No matter what's going on, you'll get to the bottom of it pretty quickly, as you happily bulldoze away.
This is an extremely powerful method. I haven't yet met a web programming bug that withstood it.