Maybe I didn't understand indexed location correctly, but Kimmo, can you explain the situation to me a bit?

I run into this where I need to connect each fragment output <-> a unique location <-> a unique draw buffer to do some WebGL 2 specific validation.  But if the above mapping isn't 1:1, then I don't know what to do there.

GLint loc = 0;
glBindFragDataLocationIndexed(program, loc, 0, "FragData0");
glBindFragDataLocationIndexed(program, loc, 1, "FragData1");
assert(glGetFragDataLocation("FragData0") == 0); // ok
assert(glGetFragDataLocation("FragData1") == 0); // ok

So if you command it to bind to colorNumber 0, it's no wonder it says that the colorNumber is 0?

I think what you're confused with is the word "location". It's not about a location similar to, say, uniform location. Even though the function name says "Location", the argument name is "colorName", e.g. an integer of 0..MAX_DRAW_BUFFERS-1. This refers to the draw buffer selected with glDrawBuffers. Each "draw buffer" entry points to individual texture color attachments of currently bound FBO. 

I think in your use-case, what you want to vary is color number, not color index. WebGL2 does not probably support extended blend functions. In this case, you say:
glBindFragDataLocationIndexed(program, 0, 0, "FragData0");
glBindFragDataLocationIndexed(program, 1, 0, "FragData1");

Or, even more intutively, you use glBindFragDataLocation, which binds the color index 0.

So if I understand what you mean by "1:1", mapping and validation: you need to form the connection between fragment output and the eventual color attachment at the draw time. So something like: validate when executing the first draw call after fbo modification, fbo binding modification, (fbo attached) texture modification, and of course modification of selected draw buffers (after WebGL equivalent of glDrawBuffers).


Discussion about the color index:

Each fragment color (in theory) is not a single color value, but a list of color values. These color values are indexed with color index. Color index is used to provide another input to extended blend function.

glBindFragDataLocationIndexed binds a fragment output to a pair (fragment color number, fragment color number index). 

The color numbers are not unique, rather they go 0..MAX_DRAW_BUFFERS-1 normally.

When extended blend function is used, the color numbers can go 0..MAX_DUAL_SOURCE_DRAW_BUFFERS-1 and color index can go 0..1. This is defined by EXT_blend_func_extended, as there blend functions only with SRC0 and SRC1. The API signature itself would support longer lists. 

In the pseudocode above, I think the program must be linked in between the phases. Anyway I'm sure you get what it tries to say..

GLint loc = 0;
glBindFragDataLocationIndexed(program, loc, 0, "FragData0");
glBindFragDataLocationIndexed(program, loc, 1, "FragData1");
glLinkProgram(program);
assert(glGetFragDataLocation("FragData0") == 0); // ok
assert(glGetFragDataLocation("FragData1") == 0); // ok

OK, I see the situation.  So here basically FragData0 and FragData1 have to be of the same data type, right?  Because they will be blended into the same destination.

Then what if these variables have different data types? Will the link fail? Do we have a logic in Chrome / ANGLE shader translator for this?

I do not think that they need to be of the same data type. I think the color conversion logic must be according to whatever the normal single-input opengl blend equation color conversion logic is -- however, I don't know by heart what that is :)

I did not implement any checks for the case, so I don't think there is such. The EXT_bfe spec does not say anything special either.

(Sorry for the late reply, I was on vacation.)

If I understand correctly, 

zmo@ created this bug to ask d clarification why glGetFragDataLocation() would return same data location for two different output names.

If I understand correctly,
kkinnunen@nvidia.com (I) answered that the data location of the outputs is the same, but the color index is different. 

If I understand correctly, that answer should be the definitive answer to the query.

I don't understand why I did not add an auxiliary answer about how to obtain the index that would be different, in order to demonstrate that something does indeed change. It might be that the index getter was not implemented (by myself) in the command buffer GL implementation, maybe because it was not used.

Closing as "not a bug".