I've played for some minutes with the feature. I see that Phil reimplemented it all. IMHO the implementation is over-engineered, but that's not a problem with me. Some comments follow, from a user POV:
Text is wider than the buffer (see logging on a 80 character wide frame). The old implementation adapted the display to the number of columns of the window. There are lots of missing options for logging. Why? Pressing `-a' instead of just `a' is awkward. And those keys require a Shift press on some keyboards. Do we really need the `-' and `=' prefixes? As a remedy for avoiding keybinding collisions, they seem pretty weak. After entering the *magit-key* menu, it is not obvious what to do. Click on the items? Move the cursor on top of an item and press ENTER? If the user presses some key that *magit-key* does not recognizes, "Buffer is read-only: #<buffer *magit-key*>" is displayed on the minibuffer. This is not very friendly. Something like "key not recognized, press some combination shown in green" would be more appropiate. Where is the help feature? It is a very bad thing that the user can't see how to get help as soon as it enters *magit-key*. Actually, he is not informed about the exitence of that feature at all. (or was it removed?) =b: (Branches) --branches Uh? Is that redundancy really necessary? As soon as some more options and commands are added, screen real state will be a problem. Why are the Switches and Actions formatted on columns, but not the Args? I guess that you want to reserve space for the text entered by the user, but is it really necessary? This puts a lot of pressure on screen real state. On my implementation, re-positioning items on the screen as the user enters Args was not annoying in my experience.
