perry is right.  the point is to have a window that provides access to a very specific set of files (these files can even be in completely different locations).  for example, i could visit "c:\music", select all files by x artist put them into a virtual folder using the sendto menu.  then i could go to "\\htpc\music" and add all music by y artist into the same virtual folder using the same sendto shortcut.  using logmonitor, you could have a virtual folder created that will automatically contain all new *.mp3 and *.wma files that you downloaded.  because this window provides access to the file's right-click context menu, the user would have quick access for copying, moving, renaming, editing, re-tagging, etc.  this is a great way to group files together that you want to work with.

a folder of shortcuts to a group of files is not as useful because you get the right-click context menu for the shortcut (rather than the file it represents).  this means that you cannot move/copy/rename the files.  a virtual folder provides access to the files as if they were really grouped together in an actual folder.

the question is what is the best way to allow all programs to access the same virtual folders.  the best way i can think of is the commandline because it can be used with the sendto menu (or a context menu item), logmonitor, scripts, etc.  The *.box files i mentioned earlier are just a renamed text file with a list of file paths.  these represent the files in a virtual folder.  for example, music.box would be a virtual folder called music.  so if the user double-clicks music.box (which is associated with filebox.exe) then the contents of the virtual folder are displayed.  also, the user can drag in more files into the virtual folder.  or, the user can add new files to music.box using the sendto menu.  *.box files are automatically saved when changes are made so if the user restarts the computer, they can still quickly access the same files.

pretend you are working on a project.  for example, say you are authoring a dvd.  this process requires that you keep track of a lot of different files in a lot of different locations.  with a virtual folder you could just drag in shortcuts to the programs you are going to use and drag in the media and other resources that you will be working with (video, audio, source and destination folders, etc.).  we can call this dvd.box.  now whenever you get home you can always launch your dvd.box and have access to the files you need for that project without having to play 20 questions with a file manager.

again, with logmonitor (my latest obsession) you could create a list of all new/updated documents on a friend's shared folder at work.  or a virtual folder that only shows the new *.mp3 and *.wma files that arrive in your incoming folder.

again, the biggest advantages of virtual folders:
- you can group files together that otherwise are scattered around multiple drives
- you choose which files are grouped together (they can be specific to a single purpose or task)
- it is accessible via commandline so it can interface with a wide variety of other applications

the interface can just be a generic window with the files displayed inside.  the only other necessary interface element would be a way to "remove" files from a virtual folder without actually deleting them.  this could be a button on the window itself or a context menu item or a hotkey - the solution here does not seem entirely critical.

well, i think i have it (in case someone is interested).  i had tried the forum and help (which i found very abbreviated and program options were only described using tooltips without description in the help file).  without real examples it was hard for me to initially grasp.  i assumed that such a common issue would have a quick answer but the huge number of options that had to do with folders and paths were all red herrings for what i was after.  after disecting nearly every option i could find and much trial and error, i finally figured it out.  it turns out that what you need to do is make sure the destination has the following syntax:
x:\foldername%File="S:n\\N.E"

bits of wisdom (don't read this unless you actually care):
make sure there is no "\" after the destination path because it is assumed in the gobbelty gook at the end.  also, replace "n" with a number corresponding to the folder depth of the source folder.  for example, if your source is "c:\path1\path2\path3" then n=4.  n represents the path depth that you are trimming off.  this way, files with a greater depth than the source folder will carry that last path information with them when they are copied.  it is a convoluted solution but it works.  the only caveat is that this process will only move files not folders so you will have a skeleton of empty folders left in your source path.  you can remedy this (i presume) by adding another commandline "action" to the stack that will indiscriminately delete all empty folders (i don't think skrommel's delempty is commandline driven but maybe i can find something somewhere).  also, make sure that the action is set to "file by file".  for whatever reason, even logmonitor's own move function does not allow stacking multiple filenames in the command.  go fig.  anyway, i agree that "log monitor" is frighteningly close to what i wanted but i am also encouraged by ruff because there is certainly room for improvement.