oh not you again!
ok i will reply only this time
Yes it is not hard. As i said, i was able to do it but i used certain amount of debugging, tracing into dlls and then hacking, patching and hooking because the ICDs are not written with the presumption that anyone else except opengl32 will ever try to load them. This is not appropriate way for every application developer to do it, but the driver vendors can just fix their ICDs to plainly work without opengl32.Then why haven't you done it? It sounds like you could write this as a simple wrapper library over WGL. So if it's "not hard to do at all," then go do it.
Ok, i will state the obvious. Yes, it is less confusing and ugly than the dummy windows and contexts. How would you explain to some newcommer what is the point to all that dummy mess? You would tell him, well, thats just the way it's done, don't ask why.Because reading through the Windows registry for certain specific registry keys and manually loading DLLs is far less obfuscated than creating two windows. I'm sure it'll be lots easier to teach people which registry bits to poke at and which DLLs and functions to load than to just use OpenGL32.dll.
If you instead read dll names from registry and then load them, then you know what it is all about.
But the main point is that it would allow you to use all gpus (even from different vendors), which you can't with opengl32.
There are more benefits. For example we can get away from the device contexts and pixel formats.
By the way did you ever wondered why opengl in windows works with device contexts instead of directly with windows? (the pixel formats are actually per-window even though you set them to a dc)
Its because back in the time when the wgl api was being designed, microsoft had the ingenious idea to use opengl directly with printers (can you imagine!) Of course that could never see any practical use, but apparently they thought otherwise. Anyway.