Thanks for the feedback regarding the UI of bundle items.
A few notes/comments/answers to issues brought up.
As for those who spoke against palettes and utility windows: I strongly dislike these things myself, so I definitely have no plans of changing to such an approach, more like offer users the ability to compose their own.
As for making the bundle item menu dynamic, that's also something which comes up from time to time, but also something I am strongly opposed to. I use functionality from many different bundles even with the same language, dynamic menus are confusing, and it already opens at the current language’s bundle (moving it up as a tool bar item may make this more apparent, and might allow having a stand-alone button which is only a short-hand to the “current” bundle, so that one doesn't have to move the mouse a few pixels).
As mentioned, I do indeed like the “search commands/snippets/macros” idea, and the addition of arguments sounds very useful. Currently this cannot be done as a plug-in, though while long-term this is likely going to be native, I do definitely want to move to a much more “open” architecture -- exactly what I mean by that will be more apparent as it happens (hopefully).
The “confusion” surrounding the Automation sub-menus: these are likely going to be removed. I don't ever use them anymore, and I don't know why people mention that they first search these, and then the gear menu -- the gear menu is the “new” way to present bundle items, and I have kept the old mainly because of the key equivalents leading to the bundle editor, and because there is a little to be said about having everything present in the top menus (though I do diverge from this with the tab and language settings).
The Text menu do indeed overlap slightly in scope with what bundle items hould be able to do (the transformations at the top), this is because the Text menu was there from day one, where there was close to no functionality written as bundle items.
As for not being able to remember the key equivalents, I would suggest reading the conventions I try to stick to, it might make it slightly easier to remember then (although not everything is following the conventions): http://macromates.com/textmate/manual/ appendix#conventions
As to not showing key equivalents in the gear menu for commands with a scope selector that doesn't match current scope, that would be a loss to me -- ideally though, they should be grayed out, when they can not be used, but that's not possible as long as the OS renders the menus.
As to “TextMate has so much functionality that is hidden”: I would suggest reading http://macromates.com/textmate/manual/ bundles#assorted_bundles for an overview -- and I would also ask you to consider how much of Quicksilver, Path Finder, Emacs, vim, the shell (terminal), your favorite programming language, etc. that you actually use? and despite the large portion of things you might not be using in TM, how much *do* you use compared e.g. to your previous text editor? Learning to use every single feature takes a certain type of person, and more importantly, it takes time -- I do think that some people may maybe have wrong expectations about how a program should be able to transform them into a superuser that master every single feature in short time :)
With the last paragraph I do not want to imply that TextMate is perfect, far from it, but I also have absolutely no ambition that users should be able to use 90% of its feature-set -- probably more like 20% (though I am regularly surprised about how much people actually do get out of the application).
Maybe that was the wrong paragraph to end with… just to make it clear: I do certainly appreciate people brainstorming about what's wrong/can be improved with TextMate, and I enjoy reading your feedback.