What about nested commands in this two-box solution (see jgpaiva's post above)? I think they would be great, especially as they would nicely match the ideas of being able to add buttons and submenus to FARR to use it as a launch bar, too (submenus = nested aliases).
I think a single edit box would be better, and I also think you should be able to specify the command first OR search for the file first.
When you start typing, FARR just matches the string against all keywords (aliases, commands) and all files - the commands should have a special icon (user-definable) or maybe even some special text attribute (bold, underlined, colored). They should not have to begin with a special character (like *), but of course you can create your commands like that if you like it.
Pressing RETURN launches the first entry - no matter if it is a file or a command. Pressing a number key also immediately launches the specified entry.
Pressing TAB+TAB uses the first file, meaning you are then presented a list of possible actions. If you want to take another file and execute a special command on it, it should be possible to select it using the arrow keys and press TAB, or, which would be much faster, press TAB, followed by the number (I think it's important not to be forced to use the arrow keys).
FARR would have to display the current command / params stack (as suggested, but a textual representation should be enough), marking the position that needs to be filled next.
To execute jgpaiva's example 'mp3 enqueue somemusic.mp3' the following sequences would be possible:
"mp3" -> FARR recognizes the keyword and shows the 'mp3' command in the list, continuing to scan for files matching "mp3" nevertheless
TAB -> FARR adds 'mp3' to the command stack, empties the edit box and displays something like "mp3 > [?]" in the status bar; the list is populated with mp3's subcommands
"enq" TAB (or press #) -> Assuming that 'enqueue' was the first match for "enq", FARR adds 'enqueue' to the command stack, empties the edit box and displays "mp3 > enqueue > [?]" in the status bar; the list is populated with the last used files
"some" -> FARR lists all files that match "some" (BTW it could even list all matching directories or keywords that modify the search path)
# -> FARR adds the specified file to the command stack, finds that no additional params are needed and executed the command
"some mp3" -> FARR lists all files that match "some mp3" (e.g. this could mean *some*mp3*)
TAB -> FARR switches focus to the list and shows that it is awaiting a file to be used with a command, e.g. displaying "? > [?]"
# -> FARR adds the specified file to the command stack (on the second position), restores focus to the edit box and clears it, displaying "[?] > somemusic.mp3". The list is populated with available commands that take a file as one of their params - this is transitive, e.g. 'mp3' is listed because it offers subcommands that accept a file param (or maybe 'mp3 > play' and 'mp3 > enqueue' should be listed immediately?)
"mp" -> FARR limits the list to all fitting commands that also match "mp"
# / Return / Space / TAB -> FARR takes the specified cmd / first cmd / first cmd / switches focus to list, adds 'mp3' to the command stack (first position), finds that 'mp3' is not satisfied with just a file param and thus clears the edit box (restoring focus to it), displaying "mp3 > [?] > somemusic.mp3", populating the list with all commands in the 'mp3' menu that accept a file param
"enq" & RETURN / # -> inserts 'enqueue' into the middle command stack position, finds that the command is complete and executes it
I think this is better because you can start typing rightaway what you have on your mind, not taking care of which box you are in. Also this approach would allow for commands accepting multiple params (e.g. two files or a file and a folder). It would be perfect if you could access submenus without having to press TAB, e.g. "mp3"-TAB-"enq" should equal to "mp3 enq" - when generally listing these commands in the format "mp3 > enqueue", "mp3 > play", "mp3 > mute", "inet > apache > start" etc. this should be possible without special treatment of commands.