Some thoughts in a bit more detail:
The Command Control Codes section of the manual should explain what will happen. It's not that confusing: If you have multiple files selected and use codes which only insert a single file into a command line then that command line will be run multiple times, once for each file. If you don't then it won't.
(If you have specific examples which don't follow that pattern then post them here and I'll take a look at them.)
They're different because, well, they're inherently different. How could they all be the same? If you don't like the differences then you can stick to only using one type of command.
Think of calling an external command-line program from Opus like calling an external command-line from a Perl script: Of course it'll behave differently to internal Perl functions.
Actions which are valid but which fail (e.g. trying to overwrite a file that's in use) will produce error messages so I presume we're not talking about them.
I agree that Opus could do a better job of helping with completely invalid commands instead of skipping them.
On the other hand, I think a bigger problem is commands which you think will do one thing but which another because of a misunderstanding. In that case there's no error message since, as far as Opus is concerned, it did what it was asked to do. That's the same as any other language, though. There's no way for the computer to know you really meant something different.
You can use the Log window in Opus to get an idea of what's actually going on. If you're creating DOS batch buttons then putting "echo" before each line is also a good aid to debugging and the doptest tool in the Tools forum is a similar helper for non-batch buttons.
It is unusual (unless you grew up with an Amiga) but it's also very succinct, telling you how to use each option with (usually) only two extra characters after the name. Once you know what the characters mean it's a lot quicker to read things like
...,FILTER/O,FORCE/S,...
than things like
...,FILTER (option), FORCE (switch),...
At least, I think so, when the command takes a long list of arguments.
Reading the short portion at the start of the Opus Raw Commands chapter and looking at a couple of examples should remove any confusion about what the modifiers mean:
[ul][li]/S Switch. Indicates a binary switch qualifier. The switch will be set if the option appears in the command-line.
/O Switch with optional arguments. The same as /S but takes optional arguments where the default action can be modified. For example, Copy takes an option UPDATEEXISTING, which may have none, size or date as a qualifying parameter.
/K Keyword. This means that the option will not be accepted unless the keyword appears. For example if the template is "Name/K", then unless "Name=" or "Name " appears in the command line, Name will not be accepted.
/A Required. This keyword or a value for it must be supplied, or else the entire command line will be invalid.
/M Multiple strings. This means the argument will take any number of strings. Any arguments not considered to be part of another option will be added to this option.[/li][/ul]
I guess they could be more uniformly named/modified.
There's might be a case for making less commonly used things like {filepathshort} into {filepath|short} -- i.e. having a "|short" modifier which can be added to the more generic codes instead of additional codes for the short paths. I don't think there are so many of them that it makes that much difference, though.
$ at the end always means a code is required ("need" rather than "want"). Provided you've looked at the Command COntrol Codes section of the manual once to know what it means I think that the $ is good as it's very common to use both the "need" and "want" variants of the codes so it's good to have the difference between them short and easy to see.
"|nopath" is rarely needed but I guess there's a case for having a separate {sourcename} or something instead of {sourcepath|nopath}. That would be more uniform.
[quote]I'm starting to think the easiest thing for me to do is to run the following external command to run a script:
@runonce: perl myscript.pl {add dopus arguments here}[/quote]
I imagine it took you a lot longer to learn Perl's often cryptic syntax than it will take to get used to Opus's syntax. We're talking about a language which uses the same symbol for pointer dereferencing as it does for code blocks and is known for programs which look like line noise.
Give the Opus commands a bit more time and you should find there are only a few concepts and warts that need to be dealt with.
At the same time, when you want to do something really complex, particularly with branching and conditional logic, then there's absolutely nothing wrong with calling scripts in other languages from Opus. I do that in a few cases. Opus doesn't try to provide a full scripting language; just a basic way to chain some of its commands together or customize what they will do when run in addition to a way to pass arguments to external programs and scripts.