I ran into the "OpenGL single config" thing yesterday when I realized that the config wasn't filtered against the attributes at all because it gave me a depth buffer when I wanted none.
Not casting aspersions it really seems like the EGL implementation (on Windows?) is very underdeveloped compared to a system that can emulate OpenGL ES. By which I mean it seems like it could work a lot better. I'm sure there's some flexibility in SetPixelFormat. I assume it supports no depth buffer for example. EGL could be much more transparent than it is (if it were designed to abstract creation of the system window object) but at the least the "config" selection system should work, I mean I shouldn't have to call SetPixelFormat myself in advance (the single config it generates comes from DescribePixelFormat, so that would be the only way) if I know I'm on WGL. This is worse on Windows because the only decent display HDC I think of to pass to ANGLE is "0" (unless it's supposed to take monitor HDCs that are kind of like virtual information querying IDs I think, and are an arcane part of Win32.) Also OPENGL currently requires that the displays all match or it can't switch contexts (
https://groups.google.com/g/angleproject/c/_1Ze8aUMn4E) which may very well be a bug.
I don't know how busy the ANGLE project but EGL seems pretty basic (is it new to ANGLE?) so I would suggest the following improvements if there's someone able to work on them:
1) Don't expose configs that don't meet the attribute requirements (I know EGL upgrades some things like color depth, but it also stipulate depth buffer depth should be downgraded, i.e. reverse of the color depth stipulation.)
2) Don't expose configs that disagree with the monitor and display adaptor they will appear on. Direc3D 9 won't let me specify the color depth for its back buffer. I assume that's because it just uses the one that makes sense. I don't know how ANGLE gets the D3D11 configs it generates but it seems like they're not suited to the monitor/adaptor if the color depth varies. Really choosing a color depth doesn't even make sense for a physical display back buffer outside of dedicated full screen mode.
3) Try to make all the backends consistent (with respect to EGL.) Try to make sure configs that match the user's attributes are included. For example, with WGL it could take the attributes it's given and test them with SetPixelFormat or wglChoosePixelFormatARB. Also it can't be hard to know what parts of the PIXELFORMATDESCRIPTOR are generally flexible and generate "configs" for them. But I've never understood why GLX uses fixed configs, unless they're really hardwired into GPU devices like. It seems like a stupid design, I don't know why EGL would adopt it unless it was the case that adaptors have some kind of config enumeration system like monitors have. In this case it seems not. So you guys have my sympathies.
[EGL is the front door to ANGLE so it's kind of the first impression we'll get when trying to test the different backends offered and see what works. Instead of feeling fleshed out the EGL interface feels thrown together, more about learning how it specifically works and doesn't work (its quirks) than just having a unified/predictable entryway into ANGLE. (I mean, I don't know, but it seems like if a config works on one backend it's very likely to work on all of them on a given system, so if I were implementing ANGLE I might try to get these parameters from a central place on the given system platform and then confirm them on the individual backends if they seem exotic or there's cause to think they would fail.)]