a) Well actually we plan to have a separate implementation for that, a more general "native window", idk if "flattening" the desktop implementation to that level as well makes sense due to the desktop history of java. Do you plan to plug another renderer into this window or do you plan to use this renderer on android via the generic interface? Also check out the JmeSystemDelegate class, it should give you an opportunity to separate this logic a bit.
I have no plan for Android yet as there is no plan to implement the second code path to support Android versions lower than 2.3 in JOGL 2.0 yet and my smartphone is under Android 2.2. I have forgotten to speak about AWT-free plugins. If Java allows to run applets without AWT one day as it was planned a few years ago (in order to get an extremely short startup time), you will be happy to have some AWT-free canvases even in desktop environments. That's the same thing for embedded VMs with no AWT support, for example for video games machines.
I remind you that AWT full screen mode is still broken under Linux with KDE 4 whereas it works fine with NEWT. If you put a (NEWT) GLWindow into an AWT frame, you lose this advantage.
b) Uhm, the lwjgl renderer doesn't bug out like that, I don't exactly know what you mean?
I know that but you could have modified the source code to call the 2 methods displaying some information about frame buffers. Anyway I have just committed another fix, please give it a try.