MRT is NOT ONLY a matter of defining GL_COLOR_ATTACHMENTi, i > 0.
As I wrote in a couple of mails (that seem to have been ignored...) in this thread, there are functionalities exposed glDrawBuffers() that are extremely handy, that allow to decouple shaders from algorithms, and that are at the core of MRT.
Simply defining other enums without glDrawBuffers() doesn't "give justice" to MRT idea.
Nonetheless, to strictly define MRT including glDrawBuffers() is not complex, even if not as easy as just increasing N.
The original FBO extension (ARB_framebuffer_object, http://www.opengl.org/registry/specs/ARB/framebuffer_object.txt
) defines the behavior of gl_FragData[N], COLOR_ATTACHMENT0 trough 15 for texture attachment points as well as the get parameter MAX_COLOR_ATTACHMENTS. This elegantly sidestepped the issue of having to define another extension to specifically allow for MRT by "future proofing" it already with FBOs. This example was not followed by the ES WG which specifically excluded MRT features from the FBO specification. I see no good reason for this decision and evidently it now leads to more discussion and more work all around. I do not have insight into the ES WGs reasoning for this, so that's where illumination would be helpful.