I skimmed through the Wiki, below are a few small comments.
I like the idea of merging the two packages, especially if the differences are indeed that small. I'm a user of the higher-level OpenGL package, instead of OpenGLRaw or gl, so I will be (hopefully...) not directly affected, but still I'm interested in the Haskell OpenGL situation in general (and sometimes OpenGL does not contain some feature, thus you have to reach for the raw bindings).
Individual comments:
* Pattern synonyms: I usually don't like unnecessary language extensions, but I can see the value of using pattern synonyms here (which is btw an awesome language feature, it's just quite new and not (yet) "core haskell")
* exact GL types vs. generic numeric types: I see two issues with the generic types. One, I'm never sure what kind of code GHC (and possibly other compilers, in the future) will generate, there may be performance regressions here. Two: Defaulting. You either need explicit type signatures for constants (which is both ugly and easy to forget), or let GHC decide what to default to, which may be for example Integer, causing serious performance regressions in some programs. Because of these, I support the exact types of OpenGLRaw and explicit conversions from the user (this is one of the two points where I have a relatively strong opinion; but feel free to educate me). Note that a "serious" user will most probably make an abstraction layer anyway, which can then handle the conversions if necessary.
* Half: I don't like unnecessary dependencies, but least Half does not depend on anything else, so as long as it remains like that, I find it an acceptable compromise.
* expanded enumerant groups in the docs: While these looks indeed useful, I have to agree with Sven that they are incorrect as of now. So maybe some new solution should be worked out here. (Also, clicking on the example, I see 10+ lines of capital letter links with GL constant names, looks kind of scary)
* XML build dependencies: I strongly agree with Sven that the ease of building the library should be a priority, and it should not depend on those hxt- packages.