The main issue with Hammer is the D3D rendering:
Hammer renders multiple viewpoints to different windows. To do that, it uses a big back buffer(bigger than the single windows) and copies parts of the back buffer to separate windows.
On OpenGL you cannot really do that. The backbuffer is tied to a window, and it cannot be bigger(or smaller) than the window. Furthermore, it is hard to copy the rendering to a different window at the end. So in order to implement that, we'll have to render the big backbuffer offscreen to a GL frame buffer object, and then set up separate GL contexts for each destination window. Then, render a quad textured with the fake offscreen backbuffer to the windows real backbuffer and present it. That needs some additional infrastructure for our D3D implementation.
On OSX we have another problem: We can't render OpenGL content to a child window. We either have to get rid of X11, or add compositing support to our X11 server. The latter is more likely, since if we were using native Carbon or Cocoa we'd need a separate window access process anyway since in Carbon only one process can draw to each window, while on Windows any process can draw to any window. We might as well just use the standardized X server for emulating that behavior.
So we don't deliberately ignore Hammer, its just a whole lot of work. Considering the amount of posts Hammer has, and TF2, HL2 etc have, we cannot justify putting this amount of work into hammer right now. Also, I haven't seen any other app yet that has this big backbuffer issue.
