It's not exactly trivial to come up with a good solution for this.

The solution you were hinting to in your other posting doesn't really scale up to be a system-wide solution.

Basically, if the UI would be a traditional desktop / focus based UI, with toolbars for most frequent commands, then I would agree more. Then how user deletes one email - taps on an email, then presses delete - and how he deletes multiple emails - highlights multiple, then presses delete - would be similar. However, with an object based UI the primary way to do a single action is completely different anyway. In the single item case the way is to tap the email, go to the subview, press delete from there. This solution doesn't scale up to multiple items, so there isn't really an argument towards shared learning and user patterns. Object menus are not a primary means to do actions.

For the object menus, although you might find some limited cases where their commands would fit the multiple selection function needs, often the object menus have more commands than what you would want for multiple selection (commands like "View details"). Additionally, if you think of a system-wide solution there are views in the system where there are more than one type of object at the same time. Say for instance a search results type view, with multiple types of objects.

What happens if the user would multiple select five emails and three photos at the same time and they would not share the same commands amongst themselves? What commands would be shown initially, what happens when the user begins to select items. It's really hard to think of how this would be done elegantly.

Furthermore, there is an issue of discovery. With the current solution commands can be placed directly in the menu, readable for the users. "Delete items", "Tag items", "Share items", for instance. Doing it in a way where the only command in the menu is something like "Select multiple" and then the commands are only revealed afterwards hides the commands: the user doesn't know what he can do before he goes into this mode and sees the commands.

And still, in the case where the user selects the command first the following view can adapt to show only contents that match this command. For instance, if the user selects "Share items", if the previous view contained items where this command would make no sense with, these items can be filtered out and a more clean view can be provided. Doing this the other way round, you cannot really filter anything beforehand. If the application supports multiple commands and content items, the user has to see all the options.

Commands first isn't imho a retrofitted solution. Feel free to propose something better, either for this application or for a global solution, though.