Ease of learning and use is one of the hallmarks of the Rexx language. The built-in Rexx commands are words, and are easily recognized by human readers. Following this standard will result in the Rexx interface being easy to learn and use. Failure to do this will result in the user having to think in two language at once, leading to scripts that are hard to read and debug (see the LSE, mg or Treewalk evaluations).
Note that I once built a Rexx interface that deviated from this. It used a "[noun] verb noun" style, where you normally dealt with a default object. However, to deal with other objects, you supplied the optional noun, which specified the object. This was based on an OO style, and worked reasonably well as such. Not really recommended, though.
While it may be tempting to make all the text in the command be the data for the command, this temptation should be avoided. First, you wind up having to choose a delimiter for textual data anyway, and then find that users have problems inserting the delimiter at the ends of the data. Second, it makes adding a second argument later in the life of the application difficult. Third, it creates the same problems as having commands that don't look like Rexx commands (see the AmigaVision and Thinker evalutations).
Error returns to commands should be chosen to indicate whether an error is minor or major, and in an order to allow "failat" to be usefull.
The normal way to process a sequence of objects is to get the first one, and then get more until there aren't any more. Error codes - if used correctly - can signal that there aren't any more.
Testing for the existence of an object is another case where error codes can be used by scripts.
On to new designs, back to nouns, or up to designing the language.
Mike W. Meyer