First: there were a few odds and ends in my last post, I was typing from my phone, and hate to do so on boards. So for that, I apologize. All of those suggestion were of major concern for me, and I am really trying to figure out the best way to make something useful.
Now, as to Roxlu’s problem (from what I have gathered anyways, as we only recently started working together, but he says that what we’ve got is working better.)
From what I can tell, it was fixed with the use of FMODs CreateStream instead of CreateSound(which ofSoundPlayer uses), combined with another feature of FMOD. Now I don’t know how is specific program is playing sounds, so I don’t know if he is using this, but there is also a feature in FMOD that I exposed that creates what is called a “Sentence” (composed of what they call Sub-Sounds). Basically you create the “container” stream, and then you can assign any sounds that you have loaded previously (Streams Only) to the container via a flag, tell the container what order to play them in, and then any time you tell it to play, it does it in the order you told it, with out gap, back to back. I need to clean up this and make the creation/management simpler, but it works nicely and I can see it being very useful.
Currently ofxSoundEngine is not a singleton, though the thought is interesting and I am considering that, but my class implementation/handling of FMOD’s System object is singleton, which addresses the issues I was having with ofSoundPlayer. One System object must be shared among all objects/classes created, and can not be copied/duplicated. So this allows the user to have all main objects (ofxSoundEngine, ofxSound, and any of the DSP units) work under one system. You can extend any of the objects without any issues, and all objects will work together. When attempting to extend ofSoundPlayer and create a separate class to embody so DSP processing, it was not working. I don’t claim to understand deeply about static objects, but as soon as I made a part of a singleton design, any class I make just grabs a pointer to the system object and we are good to go.
DSP is hashing itself out currently, with two steps forward and one back, but most of your suggestions are great. SoundGroups/ChannelGroups are what determines the issues of Parallel and Series(for the most part) that you mention, so that is why I am pushing that stuff into both the ofxSound and ofxDSP base object so that it is as simple as possible to deal with chaining.
3D (including occlusion and position) will all be available *eventually*. There are tons of things addressing 3D in FMOD, and I want it to work well with other addons as you say. That being said, I started this project for 2D needs, and want to knock that out of the park first. Plus, 3D being a huge area and one that I am slightly new to; currently my plan is to make my objects so that it will be easy to just expose or possibly extend these later.
I am trying hard to make this a simple and powerful library, and not just a wrap of the API, which is proving fun, yet difficult. This is my first big C++ project, so I am learning TONS. This is what is causing my slow speed, and I apologize.
The code currently follows a lot of the design characteristics of ofSoundPlayer as it started as an extension of it, but turned into it’s own system. Therefore I currently am using the C APIs, but am already working towards changing that also, down the line. 
More to follow soon. I need to create a stable version of the sound portion (DSP is in the middle of a rehaul at the moment) so I can post up code. Source Repository is set up at ofxsoundengine.googlecode.com though currently the source is 4 days old, and may be buggy.