As I came to this thread, I was most concerned because I had been running a shield for some weeks, just to see how high the seconds counter would go. In the event, the thunderstorm came first (and we had more today).
I was not quite sure how to determine whether this was a faulty or "fixed" board, so to test it I used the "Diode Test" range on the meter to test between D10 and ground on the shield - sure enough, it read 0.7V.
OK, I'm not happy. My solution? Well, I note that the holes on the LCD panel itself are unusually big, and it is relatively easy to suck out the solder on the top side (partially as it turns out that there is only solder on the top side anyway, it has not fully filled the holes). Where pins were still "tacked" to the sides of the holes after a second suck (it is often useful to put more solder on the connection for a second suck, so that it is all liquefied by adequate contact with the iron), they could generally be released by warping or twisting the pin with tweezers (that is a pair of epilation tweezers in the photo!).
Now revealed is R7 and the transistor. I don't know about the original, but R7 on this specimen (note all the spelling mistakes) is not 10k, it is actually 1k! What I did was to shave out the track between R7 and the transistor and move it over this gap - the pads already suited the purpose.
Many other alterations are possible but I did not fancy finding my SMD stocks, so now D10 connects to the transistor via 1k and nothing else.
Next I mounted the shield and plugged in power. Nothing appeared. Until at least, I looked closer. In fact, the test sketch was running as before, but no light. No voltage (at all!) on D10 either, unless I put the multimeter on low volts between D10 and Vcc, when I saw some light.
Had I fried a pin on a Mega2560? Well, no. The sketch is Mark Bramwell's July 2010 LCD panel test which uses the six-argument LiquidCrystal lcd constructor which makes no reference to port 10, thus it remains an input. Adding the lines
pinMode(10, OUTPUT);
digitalWrite(10, HIGH); // set the LED on
brings up the LED illumination and in fact, commenting out the first so that port 10 remains an input, makes virtually no difference though the voltage on D10 is only about 0.8V rather than near Vcc.
So I have a shield which is (now) safe, but expects D10 to be activated, if only using the internal pull-up.
A thought - if the digitalRead() call actually reads the pin state, then it would be possible to set it high as an output, then immediately test it to see if it is actually high, and if not, deem it to be shorted and alter the sketch behaviour accordingly.