WEBGL GL_EXT_draw_buffers broken

Irresponsible change breaks existing WEBGL GL_EXT_draw_buffers API (I guess it was this one: https://github.com/KhronosGroup/WebGL/pull/2780/files).

The change is responsible that pages like this one no longer work correctly: https://www.wothke.ch/269life (for details see my respective https://bugzilla.mozilla.org/show_bug.cgi?id=1645800).

The problem not only breaks existing functionality but there is NO workaround that would allow to fix the broken pages with a reasonable amount of effort (i.e. pages that rely on higher-abstraction frameworks like THREE.js and where different shaders that use different numbers of additional attachments are mixed for the different surfaces of complex 3d objects.,). It counterproductively prohibits respective usage patterns that previously allowed a maximum reuse of a framework's (like THREE.js) built-in single-attachment shaders even in contexts where some custom multi-attachment shaders are involved.

Given the weeks of my work effort that have been destroyed by this API breaking change, I would like to at least see a reasonable justification why it was "necessary". I am convinced that the benefits of the original API far outweigh those of the broken one and ideally the respective change should be reverted!

Review the API change in linked pull request #2780 and compare it with the failure described in Bugzilla 1645800 and the wothke.ch/269life example. Determine whether restoring the previous GL_EXT_draw_buffers behavior would recover the affected usage patterns; done means a justified compatibility decision, ideally backed by a regression case.

Written by the indexing model from the issue text.