Sorry my English.
When i import OpenGL Extension function pointer, i get pointer from ICD driver direct (for any OS).
When i use standart function, i get pointer to stub function from opengl.dll (in Windows). And that stub call driver routine.
I suggest: all (and standart) functions should be exported from driver like other extensions.
This is fastest (one call shortest than stub call), logically more completed, and more system independent. Setup code for fastest access may be simpler.
If you woudl have at least informed yourself on the topic, you would know, that current limitations of the opengl32.dll are due to Microsoft that doesn’t allow a custom wrapper to be written for their platform.
Besides, static binding has a number of disadvantages. Imagine the application that can use either GL 1.5 or 2.1 — it will fail to load on a 1.5 machine if static bound. In this case, dynamic binding is more flexible.
You did not understand my suggestion properly.
I am not promote other wrapper than Microsoft opengl32.dll,
and i’m not use static binding - i use dynamic binding.
After all - i bind functions after choose OpenGL version/format.
But, when i use (for example) Intel OpenGL driver (for integrated video), i can get address for driver routine by wglGetProcAddress(“glBegin”).
But, when i use wglGetProcAddress(“glBegin”) for NVidia, it get NULL, and i have no choise except as use stub from opengl32.dll by GetProcAddress(libhandle, “glBegin”).
If all drivers export standart functions by OpenGL extension mechanism - it is good imho for dinamic binding - faster, simpler, more portable, more OpenGL-version-correct.
Oh, sorry; I was being stupid. But this problem you describe is easily solvable — just define a fcuntion that would call either wglGetProcAddress or GetProcAddress… Anyway, I don’t think that IHV would care about your request…
Of course, this problems solvable, and i was forced to solve this problem exactly in your manner - first probe driver for export and second find MS stub.
But MS stub is spare (superfluous?) level of indirection and hummock on flat path.
If driver will be completely independent from Microsoft DLL - its good. Just one point to import - wglGetProcAddress and possibility to choose (in driver) proper optimised function pointer by pixelformat/destination. This choose impossible in (universal) MS dll.
Universal function should choose from all driver code-branches.
By wglGetProcAddress we may import function for current window
pixelformat/destination.
So my extended suggestion - specialized import everything by wglGetProcAddress, depend on window mode.
It true that it is faster but how fast?
Will it double/quadruple my FPS?
Nope.
Well, let me put it this way: your suggestion is a rather cosmetical one, therefore it is unlikely that IHV or someone else will ever care about it.
I second that suggestion, but for a completely different reason:
When every function has to be loaded via the extension mechanism, my hope is that the misconception of the extension mechanism being just a hack is going away.
But I guess we’re lucky: With GL3.0, none of the old functions are going to be used anymore, so we’ll get exactly what you are asking automatically 
I happen to like the extension mechanism. You know there’s going to be some give and take with all the language bindings there are, and I can’t imagine a better trade.
OpenGL extensions: the right thing to do, and a tasty way to do it.