It might help to understand the problem from a different perspective.. Let's say you're the programmer who's been charged with adding a task scheduler to Windows. How would you do it? You have several problems to contend with: If the task is run as someone other than the logged in user, should you annoy the logged in user with any error popups? What if there is no logged in user at the time the task is run? What about the difference between a GUI program and a console program? GUI's don't have stdin, stdout, and stderr; the concept is meaningless in them. What about programs internal or external to COMMAND.COM/CMD.EXE? Or other scripting engines? What about paths with spaces in the command name? Or in the parameters (options/arguments)? (As you're trying to deal with now..)
While I'm not 100% certain about the internals or full technical details in this case, the answers seem to be.. Tasks are run in an isolated, non-interactive session, which cannot interact with the currently logged in user (if any); It's run expecting there to be no console output, since it's non-interactive, it cannot just interrupt any logged in user to show the output, anyhow (and if there is output, stdin is the bitbucket/NULL, stdout and stderr get logged to the system logging facility); Spaces are handled by bypassing the issue: the command name is taken EXACTLY as is, and parameters are passed to the command are specified in another input box in the Task properties.
What all the means is that your task has to be run as if it were like a daemon (in the Un*x world). Everything is static and precise. The command name is the actual command name, without any parameters. This often includes running command/script interpreters, such as CMD.EXE! The parameters, if any, are specified elsewhere, and must be known when you set up the task (that is, you cannot change the parameters "on-the-fly"). And so on.
So, if you want to include parameters, you have to use the parameters section to specify the parameters. The Task Scheduler does not try to parse the command name to split it in to "command" and "args" like command line programs do. It just treats it as one big, full command name. Likewise, if you want variable parameters, like using %1 .. %n in BATCH files, you cannot do so from the Task Scheduler itself; You'll have to find another way. (Note that you cannot use environment variables, either, since the environment passed to the program depends on the environment the task is started with, NOT the "current" environment.) You could use a temporary file to save the parameters, but since you must specify a static filename in the Task properties, what happens when you are on a network with 5000 users and four of them try to run the same task at the same time? They'll all clobber each other trying to write to the same temp file at the same time, probably not what you wanted, either. (There are solutions to this problem, too, but that's going too far outside the scope of this question and answer..)
So final answer: In the simple case -- the path you want to pass as a parameter is static and does not change -- you either have to specify the parameters in the appropriate Task property (Arguments) rather than in the Program/Script box, or use a batch file. In a more complex case -- you'll need to ask the right question or research how daemons work and how to use locking/semaphores and such for inter-process communication (IPC).