yup, what BCOM has done is an improvement over what any of the other ARM GPU vendors have done so far. I'm certainly not criticising that. But it amounts to an open source EGL plus a GL shim, not a GL driver.
Perhaps the line is blurry about when a firmware is just "some microcode" and when it is a driver. In this case, the "some microcode" on r-pi runs threadx, it includes the shader compiler, and basically all the GL APIs map 1:1. This is most certainly not just "some microcode". Since, afaiu, the display hw is also controlled by the videocore cpu/coproc, you could probably port some gles apps and run them directly on the coproc, if you had the src to that "some microcode". So the line may be blurry, but the r-pi is so far past that line that it doesn't really matter.
So I'm not criticising what was released.. I'm only criticising that it was called an open source driver, when it clearly was not.
As far as the open source drivers keeping up w/ new generations of hw.. well, it is true to some degree. But there has already been a huge amount of progress in the last year or less. Of course if it is always based on r/e products that are already released then we'll always be a bit behind. I would hope that eventually we can get to the point where some GPU vendors start working with the open source community, releasing specs, etc, like AMD and intel do in the desktop world.
At least on the plus side, we don't have the huge reclocking complications like there is on desktop GPUs. For the ARM embedded GPUs all the clock control is in the open src kernel drivers. (Well, maybe not the case for r-pi, but at least for all the mainstream embedded GPUs.)