No disagreement that we need to fix this. There is a lot going on in this dialog beyond just typing data in cells. First, population values in NORMA always resolve back to an underlying ValueType at some level, so there are existing values to choose from and match. Secondly, you get the issue of complex identifiers (nested complex identifiers, etc), which resolve to multiple underlying values, resulting in complex item expansions that enable both pick lists and inline creation. At the surface of just typing in a few values it looks like a trivial problem, but things rapidly get more involved in the complex cases. Here are a few things that I don't like, followed by some of the technical issues that need to be resolved to fix them.
I'd like to see the dropdown active when a cell is activated, regardless of whether or not a textbox is supported. This gives an indication that there is data available in the dropdown.
There is little reason to have an edit field active for readonly data, the dropdown will do. Having a readonly edit field active is misleading.
Typing in a cell should move it directly to edit mode, if available.
There are a handful of reasons I haven't fixed this up yet. If the solution were trivial I would have fixed it long ago. This will fall on the SPD list after the ability to do instances of subtypes, which is also a non-trivial workitem (I have that one well on its way, but it wasn't ready for the May 2008 drop).
Technical issues. (You may not care, just showing that I'm not slacking):
There are four levels of activation in VirtualTreeGrid control that is used for the sample population editor. Note that any of these go well beyond what a standard tree control would offer (Explicit and Delayed, in place basic textboxes only). Explicit (triggered by code or the standard F2 key), Delayed (click with the mouse, it wakes up eventually), Immediate Mouse (same as delayed without the delay), Immediate Selection (activation occurs when a cell is selected by any means). ImmediateSelection is basically what you're asking for, and something we do in other windows (the New... dropdown in the Reading Editor is ImmediateSelection, for example). The issue is that any immediate selection inline controls need to extremely careful to not interfere with normal tree and/or grid navigation, so the mode is not generally used with controls that activate TextBoxes, which eagerly eat navigation keystrokes.
There is a nasty WinForms bug that causes problems with focus when an inline control is deactivated because of a focus change. Basically, the framework doesn't check that you're already losing focus and sends focus somewhere else. If you're wondering why you hit Escape and the toolwindow deactivates, this is why. These issues need to be handled on a case-by-case basis, and even then it can be pretty touching. I reactivated this bug repeatedly inside Microsoft, but I left before I could bully it through internally and they've never fixed it.
To fix these items and get the behavior we all want, I need to extend the existing control (or create a new one) that is active and waiting for keystrokes, but does not eat navigation keys or show the edit window until something other than a navigation key is typed, the control is clicked, or F2 is pressed (typical spreadsheet behavior, but this an instance pick-list dropdown on each). I obviously need to figure out the focus issue as well so that escaping an edit doesn't send you focus to Timbuktu.
In the meantime, the keystrokes to know are F2 (activate an edit box) and Alt-Down (if you have a dropdown button, then open it).
Hopefully that gives you a better feel for where I'm trying to go. I'll let you know when I'm there, but the comments on this issue make it clear that I need to do something soon to make sample population workable.