New error when mixing gl and gles on web service
I am working with an open source project called [lovr](https://github.com/bjornbytes/lovr) which [uses glad](https://github.com/bjornbytes/lovr/tree/master/src/lib/glad). Its current GLAD generation link is [this URL](http://glad.dav1d.de/#profile=core&language=c&specification=gl&api=gl%3D3.3&api=gles2%3D3.0&extensions=GL_ARB_texture_storage&extensions=GL_EXT_texture_compression_s3tc&extensions=GL_EXT_texture_filter_anisotropic&extensions=GL_EXT_texture_sRGB&extensions=GL_OVR_multiview
).

Sometime in the last week or three, this URL stopped working. Attempting to generate a GLAD from this URL on the web service now results in a message

> Warnings/Errors:
> Core profile not available when selecting any gles API, automatically changed

It then generates a Compatibility profile.

When I spoke to the lovr developer, he explained that the goal was to get a Core profile when running with plain GL and whatever profile when running with gles2. This is because the code targets both desktops and on emscripten, and Desktop-OpenGL Core is more similar to gles2 than OpenGL Compatibility is.

There are two issues here:
- What would be the correct way for lovr to get its gl core + gles2-supporting headers? I don't know what it was the web service was doing before when it simply allowed "gles2 core", but it *worked*.
- *Even if what Lovr is doing is incorrect*, it is problematic for there to be URLs which previously worked on the web service but now no longer work. I maintain a fork of Lovr where I use additional extensions that Lovr master does not use. Previously I could add or remove extensions by loading Lovr's URL up and changing the extensions list to add or remove one or two extensions. However now running the URL produces a compatibility profile, which is not what Lovr targets. In other words, removing support for core+gles outputs means third party consumers of older GLAD-using projects are "stuck"— I cannot necessarily patch Lovr to migrate it away from "core+gles2" because I do not directly control the original project, but I can't generate a new core+gles2 source file either.

I am not certain what my "expected behavior" here is, but: Would it be possible to alter the web service so that generating the "illegal" core+gles2 profile either becomes a *warning* (ie emits the illegal profile rather than silently altering it to compatibility) or provides more useful advice about what to do?

Thanks