I'm curious to why you say GLEW's Core Profile support is experimental?
CONST_CAST(GLEW_EXT_vertex_shader) = _glewSearchExtension("GL_EXT_vertex_shader", extStart, extEnd);
if (glewExperimental || GLEW_EXT_vertex_shader) CONST_CAST(GLEW_EXT_vertex_shader) = !_glewInit_GL_EXT_vertex_shader(GLEW_CONTEXT_ARG_VAR_INIT);
First it's checking for GLEW_EXT_vertex_shader. Then if glewExperimental is true or if the GL extension exists it initializes the related glew function pointers with getprocaddr calls.
So, experimental forces the instantiation of all function calls, whether or not it is an extension reported as supported by the driver. Using that in production code seems like a time bomb to me, and something you only want to do if a vender gave you a driver build to test.
The GLEW release notes are for the same version as reported as bugged on opengl.org. So it looks to me like the support for the core profile is effictively non-existent due to the need to enable glewExperimental.
The choices seem pretty obvious.The SDK's GL Load is large, monolithic, and comprehensive, like GLEW. It has to be initialized before being used, like GLEW. You have to compile it into a library, rather than just including the source in your project.The generator is, by contrast, much smaller. You pick the extensions/versions you want, so your headers are smaller and (more importantly) cleaner. But if you suddenly have need of an extension or version you didn't generate, you'll have to regenerate the source.The generator produces simply headers and source files, which you can include directly in your project. So it's a bit easier to use (though obviously, for any real project the difference is negligible).And the generator has different generation styles. Like the noload styles, that make it so you don't need initialization (like GLee).What's better depends on your needs. The SDK's GL Load component doesn't depend on any SDK component, so you can extract it if you want.