Thank you, Nicolas.
I think this behavior is wrong, then, or else I have some configuration setting that's messing things up. Problem is, if you create sub-level todos, and change their state, the updates all get muddled, and you can't tell which one's state changed. It also creates multiple logbooks if you go back and change the state of the main heading at some point. (I also can't help but wonder if this is partly due to changes in org-mode 8.3 regarding property drawer syntax.)
Here is an example to reproduce some questionable results:
0. Create a set of TODO labels, like so:
#+SEQ_TODO: TODO(!) PEND(!) DONE(!)
1. Create an item, make it a todo. (Creates a logbook.)
2. Create a subheading. (Alt-Enter, shift-right) Make it a todo. (This adds a line to the logbook saying the state changed to TODO, even though the previous line says the state already is TODO. You can't tell which state changed.)
3. Cycle the state on your sub-todo to PEND. (Changes the state in the logbook.)
4, Go back to the main heading and cycle the state to PEND. (This creates ANOTHER logbook right underneath the heading showing the state change. The original record for when it was marked TODO is in the other logbook, but there are two such entries, and it's not obvious which one is which. You could probably infer logically that the older entry is for the main heading, but if states keep going back and forth, you'll lose track quickly.)
This can't be a desired behavior for anyone -- you either want multiple logbooks for each item and subitem, OR you want a single logbook the whole time. And if someone wants the latter, I don't see how it can be at all useful if you can't tell whether the main item's state was changed or one of the sub-items.
I could debate whether this is a bug, but my emacs is nothing if not versatile, so bug or not, I'm fairly confident there's a way to get the behavior I DO want. To that end, I was hoping somebody could offer a suggestion.
However, the more I dive into this, I think the easiest fix is to define org-metareturn-hook to call org-cycle (to collapse the drawer) and org-end-of-line (so it's positioned after where the drawer would be) BEFORE invoking org-metareturn to add the subheading. Actually, I'd probably want something more specific than org-cycle, since I don't want it to expand the drawer or some other tree node.
Any thoughts on this approach as a solution to my issue?
Thanks,
Keith