I'm sort of replying to your other thread here too (about the notification broker).
Probably the only way to pull off the level of control you require is to implement A2DP via both types of stacks within your app. You would search for and find headsets, connect to them, and stream the data yourself. That might solve your latency issue too, if the problem is on the PPC side.
Well, I would have to say it would be really, really tough to pull off. Try finding some sources dealing with A2DP. Keep in mind anything you implement will have to be done for both the MS and Widcomm bluetooth APIs, which are as different as they could be.
I don't know what type of service the headphones would expose for the buttons, or if perhaps that is included in A2DP.
Sorry, but I have zero experience when it comes to A2DP specifics, and can only provide the most rudimentary BT advice. In my case, I've implemented a PC based custom BT service (a crude TCP/IP proxy server) running on the MS stack, and a client end on the PPC supporting both MS and Widcomm stacks, that allows me to transfer data back and forth between the two. The PDA initiates the connection, and will iterate all BT devices and find one running my service, and make a connection if one is found.
So I don't have experience using any of the standardized BT services at all. I use the RFCOMM protocol (which is one of the few the MS stack supports), and am proprietary on both ends.
You can read my lamentations
over the two BT APIs if you want more specifics on how they differ.