Quotelevel editor
move them as a single unit via drag-and-drop
how best to argue for the object-first model
The movement target can be complex, e.g., place a cluster of pieces as a unit into a given gap, such that the cluster is centered within the gap. You don't know where any single block will end up before you have moved the entire cluster. Object-first allows for WYSIWYG here.
We can abstract over such clusters in the data model: Create group, add each piece of the cluster to this group, move group. This works in both the object-first or the verb-first world. Maybe this abstraction in the data model is better because it captures our intention: We wanted to move the group as a unit, with requirements for the unit rather than for loose pieces. The downside is that the data model becomes more complex. You're forced to define the map layout in a high-level language.
Quoterapidly assign the same skill to multiple rodents
Good reason. You need more speed when you assign the same skill to n rodents, compared to the speed where 1 rodent accomplishes several skills, necessarily one after another.
Even for a single assignment, verb-first is fast. While I'm still aiming and clicking with the mouse on the rodent, I have already hit the skill hotkey with the other hand.
Quote"sticky" selection on a lemming, during which clicking on a skill automatically assigns it to the selected lemming--essentially an object-first method special-cased for the hero lemming.
IMO, this points at a fixable shortcoming of the normal assignment. With directional select and priority inversion, I haven't seen the need for object-first. Long levels with lots of assignments to a hero maybe.
With object-first, but without directional select or priority inversion, you must select the object far ahead of time, before the rodent gets clustered. That should be unnecessary: Assignments happen at a single time, but its input must now span over a long time interval.
QuoteBut habit is a mighty powerful thing
Yes!

-- Simon