On 1) I am in no way affiliated to AOL, and cannot tell whether they will disclose it some time, but I think the answer is no. Not sure whether they are aware / interested they still own it in the first place. The repeated discussions about that topic lead to nowhere. However it is possible to clone MD2, as demonstrated by...
So it does not seem to be too difficult to rebuild MD2 from scratch, and it seems to run fairly well. The main difficulty is certainly to make it entirely compatible, in order to use the old presets. Without this restriction however, it should not be a huge problem to write your own "MD3" or however you would call it.
2) I'll have a look when I get around to it. For your better understanding, these are the main limitations:
CPU: You can program any fractals you like using the per frames equations. There is a full programming language and unlimited storage space. But you can only draw 4096 polygons per frame, which makes it painfully slow.
GPU: I would not seriously consider anything else than the shaders for programming fractals. That is fairly well possible in MD2, except for 3D/ volumetric calculations. Realistic smoke and flames for instance require 3D modelling, which cannot be done in MD2. That is however not such a serious drawback, because the 3rd dimension increases the numeric effort to a degree it cannot be handled anywhere near to realtime anyway on a standard machine. I only got anywhere with my mandelbox flights because I found a trick to reduce the 3D space effectively to 2D. Concluding, in MD2 we have (a) no z coordinate.
We neither have (b) objects. We cannot place an object such as a polygon to the screen at position (x,y) other than by using the shapes provided by the CPU. That is not too bad because fractals normally don't need objects. Except e.g. Incendia, which can create stunning images by placing 3D objects at positions determined by fractal equations and then rendering them... calculation time: bloody ages.
We have (c) no memory over frames except the screen. The shaders cannot remember anything between two frames other than the RGB of each pixel. That defeats concepts to distribute the calculation over several frames. It would be an obvious idea to do only, say, 30 iterations per frame, store the intermediate results and continue in the next frame, but that is not possible.
There is (d) no way to exclude pixels from being calculated. This limitation is owed to the physical structure of the shader units. The shader always executes the complete code for each pixel per frame. So if we consider to render only one per 8 pixels per frame, to reduce the GPU load and make it run smoother - that does not work. AFAIK, the shader always executes all branches of conditional statements and discards those not required so there is no benefit in excluding pixels by IF conditions or similar.
There is (e) a limitation to the number of GPU instructions. With shader model 3 it is 1024 (may be higher nowadays, don't know). This puts a limitation to the complexitiy of fractal equations and iterations, at least if the compiler unrolls the loops for speed. Whether it does or not you can never be sure. The compiler can be advised not to unroll loops but MD2 does not provide access to this control. This limitation is however not too bad because 1024 instructions will make the GPU stutter along at very low framerate anyway, which is no fun to watch.
The numeric precision is (f) limited to IEEE single. That imposes serious restrictions to the level of zoom possible.
3) I don't know Fractron, and I seriously try to avoid installing MS's shitty framework whatever dot com... that said, I think I already installed it for Incendia and it caused me a lot of problems. I hate software that requires this crap.
4) Can you point me to this documentary ? Do I need to install Fractron for it ?
5) Thanks for the pdf, this is interesting reading. Will have a closer look.