Just a small update based on some tests I did trying to get the MDD to shapekey pipeline worked out. Since it seems the Explode modifier separates faces from a mesh to create the “shrapnel” faces, I tried working around the vertex count change this would cause by actually separating the faces of my test cube from each other before setting up the Explode modifier. The idea is that the mesh would already have the proper vertex count, same as its “exploded” form.
The result I got was not a success but still enlightening, I think. Exporting the explode mesh to .mdd and then importing it as shape keys on a dupe, the animation was preserved in a weird sort of way. Portions of the duped cube fell away from the source cube in what appears to be the same pattern as the original, but at right angles, as if there is an axis-shift issue. But worse than that, the shrapnel faces were highly distorted. This would have been a total failure except that I’ve seen this kind of distortion before, in trying to create shape keys by copying then from one object to another using a script, in 2.49b. I found then that vertex count is not the only factor that must be matched between objects for shape-key copying – vertex order, i.e., their indexing in the mesh data, is also critical. When the indexing does not match, you get highly distorted versions of the shape keys, but the shape animation is preserved. What I surmise is happening is that the vertices are being translated according to the shape key data, but because they don’t have matching indices, the “wrong” vertices" are being translated by any particular data in the shape key set, leading to the distortion.
For the Explode modifier, getting similar results leads me to think that the faces used for the shrapnel are actually generated by the modifier as new faces, and the originals deleted in some fashion. This would result in a matching vertex count for originals with pre-separated faces, but the indexing would get slapped around pretty bad, leaving the shape key data to affect the wrong vertices when imported.
This is all speculation, of course, based on only a few empirical tests, but it does seem to indicate that a workaround isn’t something that’s just going to jump up and introduce itself in an “Aha!” moment.