> every command you send to it has to first be announced with a prefix keystroke.
That's not a bug - that's exactly how every container-style program should work. That way, whatever is running inside the container, talking to the container can never get in the way. It's probably the most frustrating thing about web browsers and most window managers.
I went to effort to make my current window manager work that way (after getting used to it in ratpoison and, of course, screen/tmux).
Well I can appreciate the idea, and there's no other solution that can handle all cases of multiple levels of nested applications that all have their own keybindings (like a web app inside of a web browser inside of a window manager). But in practice I find it to be a horrible experience to use. I used a typical hipster OS X + tmux + vim setup for over a year a while back, so I speak from experience.
Graphic software vendors have essentially all agreed to never use the super key (aka windows key aka command) in their default configuration, an artifact of the time when you couldn't rely on computers having a super key, and of Windows reserving the super key for itself. Most modern window managers only use keybindings that involve the super key. Or at least Gnome 3 does, kinda, except for alt-tab and a few other bindings. Anyway, my window manager config only uses keybindings involving the super key.
It's a much more pleasant window management experience.
But yeah, I don't think there's an alternative that tmux could have used (though mouse integration could alieviate a lot of pain). But that's in itself an argument in favor of not using tmux to manage windows.
You can configure prefix-less keybindings for tmux. It might not be a good idea to do globally unless you know that none of your terminal apps will depend on the same key, but having that in per-project (or per-language) configs might be ok.
I find mouse and clipboard support a bit annoying but there's been changes to that in recent versions of tmux and I haven't reviewed what they do yet.
I haven't got to that part quite yet, but I've been considering adding a few global key shortcuts that would route e.g. run/continue/next/step to my debugger window, regardless of which tmux window is active.
That's not a bug - that's exactly how every container-style program should work. That way, whatever is running inside the container, talking to the container can never get in the way. It's probably the most frustrating thing about web browsers and most window managers.
I went to effort to make my current window manager work that way (after getting used to it in ratpoison and, of course, screen/tmux).