I was about to post a related request but as it happens your post is on the top of the list and very much related to what I'm about to suggest here. If you find my suggestion to not be solving what you are asking or otherwise blur you message, give me a hint and I move my stuff out to it's own thread. Why I post it here is because I think it solves your ideas. It does does not just handle folder but bookmarks as well:
I would like if the Favorite or Bookmark Bar seated above the rendered webpage but under the Toolbar would facilitate a more Finer like way of doing things. A spring-loaded folder type of way for grabbing an URL or a newly created folder, hover over a relavent folder in the bookmarks bar and it would spring open and any subsequent folders in it would behave the same way to let us reach the correct location for the bookmark if it is buried deeper down and finally some neat way of naming the Bookmark with the default suggestion filled in but i edit mode. A hit on return or a click any place else, and voila your done.
As it is now bookmarks handling use a paradigm with many similarities to general file handling but fails short of things that Finder use that could be used for bookmarks as well. Let alone it need some special implementation but there is undoubtedly an inconvenience to have to open a dedicated bookmarks handler in its own window for such a simple task as to drag and drop a bookmark object to a location within the bookmarks directory structure of your choice. Ideal would be to be able to edit names of bookmarks and folders in the same way you can do in Finder with a sudden click on a files name which enter a edit mode and return or click elsewhere saves the new name and exits edit mode. The name edit isn't implemented with spring-loaded folder in Finder but it should. For the same reason I think a name edit should be part of the bookmarks spring-loaded folder and perhaps it is even more important since new bookmarks to store is almost everything we do and less moving and structure messing in other ways is needed for most of us I believe? Compared to the Finder stuff we do I mean.
In Finder you can select a file which highlight it. I don't see this as necessary for the bookmarks reached from the bar here. Perhaps I haven't thought it out enough but a normal click would need to be generating a webpage so the naming should just be implemented with the 'sudden' click style, not with a selection which highlights the object and then followed by a hit on return/enter for entering name editing mode, since a selection shouldn't be possible at all except for editing mode, since a normal click should result in loading the page and nothing else and the other option is sudden click which gives name editing. Think of spring-loaded folders with added name editing to the end when the object is dropped and you will get the grips of what I meen I believe. The drop isn't the last thing, the confirmation of the name is.
The following name edit thing could either be a graphical freeze state that let your bookmark or folder hang were it was left of with the underlying structure behind it still visible. The focus must be given to the bookmark or folder of ours and clearly display that the edit mode for the name expects your attention and either we enter a new name or just hit return or click elsewhere to finnish things. Alternatively the naming could be implemented as a dialog in a small popup but otherwise just need a hit on return or click elsewhere to save everything. A drag'n'drop and a hit on return or a click somewhere would result in what today need you to open a new bookmarks handler etcetera. The inconvenience with bookmarks further the distance between the user and the users decided structure. Therefore it is a two folded benefit from improving things here. Not just the short term convenience for the user when saving new bookmarks, but the whole structure would be easier to remember which means easier or more likely to give proper attention if the tools always presented the structure and in such a way that makes it trivial. That is a general rule to some extent.
Bookmarks handling is what I see as having a potential for improvement and even let OmniWeb further the distance to the others if they not surprise us. The WebKit underpinnings let you always stay on par with Apple Safari on rendering stuff and such, so it would be possible to be the best of the best with a realistically amount of effort. Much of the OmniWeb unique stuff is already implemented in such a good way I don't see any improvements needed at all. Bookmarks handling is different, especially the most uncomplicated almost daily task to just grap an address and place it in the dir structure should be done in a single drag and drop with option to renaming or set for the suggested name.