Early on, we decided to have bind group layouts automatically de-duplicated. I believe that the combination of this logic with the implicit layouts of #446 results in a footgun for the users, and we are already seeing related ISV questions.

Here is what happens. Users have multiple entry points (doesn't matter if the same shader module or different ones). They getBindGroupLayout from one of them and assume that the relevant bind groups work with other entry points. This assumption is based on the fact they are accessing roughly the same bindings.

However, implicit BGL considers static use. So minor changes in the shader may result in the "static use" set being different between entry points. If this happens, the user code would not complain up until the draw time. This is counter to what we've been trying to accomplish: detecting and rising errors as early as possible. This becomes a serious footgun.

I think, we should solve it in either of the following ways:

1. Declare in the spec that each getBindGroupLayout result is strictly unique (soft solution). This means, users can still use it for unique pipelines, but once they need to share any BGLs they are explicitly asked to declare them up-front.
2. Remove implicit BGLs entirely (the hard solution).

Side note: implementing this in Gecko has been a pain. The best solution would be to have getBindGroupLayout and createBindGroupLayout return the same JS object considering the deduplication. But JS objects are createdon the content side, immediately, and getBindGroupLayout today can't work with content-side deduplication. So it forces us to go into the woods of returning different JS objects that then converge into a single thing somewhere deep on GPU process side. This is very annoying, and worst of all - I don't think it serves valid use-cases for the users. It's the complexity that should be avoided.