Back at a computer now. It's {allfilepath}
I remembered why this won't work when you select files and push return, however. In that situation, each file is handled separately rather than all the files at once, so {allfilepath} will only return one file at a time, and the command will be run once per file.
(That doesn't affect other situations, like selecting files and running a toolbar button, hotkey or context menu item.)
Just as I thought, there is no way to make it work as described for return key (i.e., calling winamp.exe only once no matter how much files). 
Can GPSoftware patch Opus so that executing files via return behaves more consistently? I think that would solve all related future problems, not just for Winamp 
Not easily, since it'd require reworking of a lot of stuff. Part of the problem is that Opus can override double click actions, and it's also complex (and not really documented) to work out exactly what the OS will do for each file before actually doing the standard action.
Changing this would risk breaking several other things, so we'd be reluctant to do so. I'm not being lazy here btw, I spent an entire day looking at it last week before deciding the workaround script was a better way to solve the winamp problem.
Ok, thanks for your time & effort, I'll simply (continue to) use your vbs script workaround then! 
Hey Leo,
I just posted my problem opening music files sequentially in WinAmp, but I then discovered you provided a script that fixes that problem back in 2012. Problem solved.
My hat's off to you. Thanks so much for taking the trouble.
epat
Hey All
Trying this solution here didn't result in the best outcome. The script takes a long time especially if there are many tracks in the list.
My current solution is using a hotkey that runs this comment:
ContextMenu ITEMMODE LABEL "Play in Winamp"
I would prefer though that a simple Enter-keystroke would do the same.
Also Shift-Enter is supposed to run the command "Enqueue in Winamp" which also exists in the context menu.
In "File Types" I only see events regarding mouse clicks.
Is it doable?
Thanks!
FileType ACTION=shellex may work better these days, at least if Winamp adds things in the order they are given to it.
Shift + Enter will run the Left Double-Click + Shift event. (Assuming you've disabled the lister hotkey that Shift + Enter triggers by default, since that's the hotkey to open a path field in Opus.)
Hello, how exactly do I use "FileType ACTION=shellex"?
Same problem with Foobar2000 2.0 beta versions and any music files.
Selecting multiple audio files and hitting Enter in Directory Opus makes foobar2000 2.0 go through the audio files one by one and only playing the last one.
No such problem in Windows Explorer.
Thanks,
Alec.
Thank you, but that didn't fix the issue.
I see what you mean with Foobar2000 2.0 beta. The 1.6.x stable versions don't need anything special here (not even the FileType command that was needed for WMP), so something must have changed on the Foobar side of things. Maybe if it's pointed out they can restore the old functionality.
It might be possible to work around it via an OnDoubleClick script add-in, but I haven't had a chance to try that yet.
I've made a note to look into this in more detail, and see if we can fix the underlying issue; if not I'll see if a script workaround can be done. If you link your account we'll look at it sooner, but I'll likely update to the new Foobar2000 myself (assuming there's a working lyrics plugin for it) at which point I'll want this fixed as well. 
For now I'm still using the stable version.
Linked the account.
Reported the problem on foobar2000 forum earlier.
Hopefully someone resolves:-).
Please see this response #321 by Peter:
The Foobar2000 developer's answer:
"I rewrote the whole shell extension in v2.0, so the shell now talks to foobar2000 using a different protocol: IExecuteCommand instead of IContextMenu. This has many advantages, most importantly avoids unnecessary loading of our code into Explorer.exe and every other app invoking these shell ops.
Mitigation on my side is possible, at cost of degraded performance (wait for more files before taking action).
I already use such workaround when adding files from command-line: foobar2000.exe . The whole point of implementing the shell extension is being able to reliably send multiple files without hacks or delays.
While Directory Opus is awesome technology, this really looks like their bug. By convention, pressing enter or doubleclicking should perform the same action as the bold command in the context menu, no? Here it clearly does something different."
It's on our list to see if we can make this work without changes on the FB2K side, just quite low priority as we have so much else on, and from what I remember of looking at it in the past it's quite hard to solve due to the structure of things. (As an example, you can select files of unrelated types and push return on them. They can't all go to the same shell extension in a lot of situations.)
It also only affects a very small number of programs, at least as far as we're aware. (But the same is true from FB2K's POV: It probably only affects Opus.)
I already use such workaround when adding files from command-line: foobar2000.exe
Based on that, the problem can be worked around without changes to either program. Changing the Left Double-Click event to run this:
"C:\Program Files\Foobar2000\Foobar2000.exe" {filepath$}
I just did a quick test and that seems to work well with FB2K v2.
Yes, this works, thank you.
Something very interesting to share.
Removed Left Double-Click event, so nothing defined for Music group or any other file type.
For a list of DSF (DSD format) files - highlighting several of them and hitting Enter - correctly transfers all of them into foobar2000 and starts playing the first one.
But for a list of MP3, FLAC, or APE files - it doesn't.
All these files are associated with foobar 2000.
Thoughts?