Hey! I already mentioned narrowing it down to a family of choices. ;-)
Both these tricks are used by IDE's (and e.g. vim). But this is still thinking in terms of a touch front-end to a conventional language. I'm suggesting an intrinsically touch language - so well-fitted to touch, that a text front-end would be awkward (and difficult to even imagine).
I like your point about choices. It seems that however it was done, it would always boil down to making choices (in some way) among alternatives (of some kind). I also seems we'd need "methods" (or, to be more general, "verbs": for something to be done).
A way to specify what a method does (instead of using instructions) is to actually do it - as macros are implemented in vim and office. Like the writer's admonishment: show, don't tell. But to invoke a method, you still need to choose it in some way - so there's the choice problem you mention again. Maybe the subset of choices available could be constrained by a strict hierarchy of macros... or maybe we could just admit that this doesn't work well with touch, and instead restrict it to a Domain Specific (toy) Language, for very specific and common tasks (rather like the macros of vim and office are arguably DSLs). You don't have to have recursion or turing completeness for a tool to be delightfully useful for the job (e.g. hammers and cars aren't turing complete).
But I just have a nagging feeling that there is a way to do a touch-based general programming language... start by going back to basics and thinking about how we reason and communicate in practice (e.g. in the physical real world) - instead of being trapped by the elaborate programming languages that we happen to be familiar with. Solving the actual problem, not forcing a preconceived solution.
What about speech for choice of verbs? touch + "this one goes here".
Seems pretty intuitive and workable actually....
