Thanks for that info, I will pass it along to my Mac buds at the office.
Honestly, not my intent to disrespect anyone's work, at the app nor OS level. I (hobbyist now) cross-platform develop using SDL and ClanLib with a lot of hardware targets at my disposal for testing, so perhaps my frustration with it is being spilled injudiciously here. But I've noted those observed "features" over the years here, too, along when new successes arrive.
It's 2012, I believe five years after the last OSX release using PPC? For machines and users, don't you find that apps switching fullscreen modes -- for things like marginal performance gains -- is becoming less and less relevant than what it was 5-years ago? That's like I've heard feedback here a lot on (for which I agree) "why are you building 32-bit MAME?" So why not a windows-without-borders *option* for 1920x1080?
IMO, I think the work Intel has done the most these past two+ years in the Linux kernel space (I might be mistaken, but did not GEM 'bring it together' for video modesetting and DRM?) has been a catalyst for all other chipsets, which in turn has brought a LOT more stability for features and performance to build upon. Despite these grand improvements, there are varying problems with app attempts with switching to a fullscreen mode, with only some mimicking failures just like these emulators, suggesting the problem lies in the graphic API / driver stack. From my personal implementations and from feedback in forums all over the globe, I find the issues and associated frustrations are because of the complexities mentioned that have been layered over the years.
But perhaps those emergences ARE converging and a bit more patience is required, because I have found the "crashes" to be at least recoverable over the days-of-not-so-long-ago of "hold power button for 6-sec" method. I still believe in stability over features over performance, and in the Linux space, frankly, you have to be and it's not something needing apologies.