hmm, the JavaFX windowing system seems cool but not sure how well a fit it'll be for LWJGL considering OpenJFX's GPL nature and the risks of depending on com.sun.*. either way its likely they'll use the CALayer approach. Besides, its not ready for OS X yet (who knows when it will be) and will not be compatible with the Apple JVM.
The reason why AWT is no longer usable is because the only way to draw OpenGL on it now is through the use of a Cocoa CALayer (renders everything to an offscreen image before drawing the final image). However for an OpenGL binding like LWJGL to work, this needs to be done twice! (yes tried to avoid this problem, including with the aid of Apple engineers but it seems to be a technical limitation of the Cocoa API). First LWJGL draws its stuff to a pbuffer and renders it to an image. Second the image is drawn on the CALayer (again to an offscreen buffer) and then finally drawn to the screen. This is pretty much unacceptable and kill performance and has all sorts of other issues. We have this working to an extent for LWJGL Applets on OS X (after some major hackage and pain) but you can understand why this is not really the way to go.
We really need a clean lightweight re-implementation of the LWJGL windowing system on OS X using the Cocoa API directly. Its really the only way to go now on OS X for a simple window with an OpenGL context on it, its future proof (as its Apples API of choice). Any other windowing library like SWT, QT, Prism, etc all probably use Cocoa internally anyway and just add bloat for our purposes. One downside is that Cocoa is an Objective-C library (but its mostly compatible with C) and the only other choice on OS X is Carbon which is Apple's old C API but this is no longer supported by Apple and likely not the way to go as it could get depreciated at any time.