I didn't intend to call the method of running things by adding another command to the beginning of the invocation "hacky." Although GUI-only users may see Bumblebee that way, until frontends / desktop support is developed.

I was referring more to Bumblebee's internal architecture: running multiple X servers and ferrying data between them.

And neither of these notes about the "hackiness" are any criticism of the Bumblebee developers: They've done great work making the software as reliable as I've personally found it to be, and getting it out there as quickly after the release of Optimus as they did, with AFAIK zero support from nVidia.

Even if the internals are hacky, as an end-user I have no complaints; unless you're messing with the config file, or upgrading from a very early version of Bumblebee, its complicated design is well-hidden from the end-user.

Doing front-ends and desktop UI integration is somewhat out of scope for Bumblebee as a project. It would be nice to have, I suppose, but I personally don't need it (I always use the command line and can figure out how to manually make launch icons if I need to), and it doesn't require the same intense knowledge of the guts of the Linux video subsystem that writing Bumblebee itself did. So I feel it would be much more logical to have those things be separate projects, since they require a different developer skillset and don't have a dependency on the internal details of Bumblebee.