Sorry, I don’t have a lot of insight about the particulars of this behavior and it’s a bit outside of what I can give code-level support for, but I can share the following observations:
• AudioSession has remained very stable and similar throughout the entire history of the API being exposed in the three years OpenEars has been using it, and AVAudioSession most likely just wraps it in some respect — just a guess, but the underlying audio code used by the high-level API is pretty likely to still be in C or C++ for performance reasons and the wrapper is probably being pushed not only because it results in fewer support requests to Apple but because it lets them make small changes in the underlying implementation, but probably not because the code used by AudioSession has actually gone away or changed massively. So my suspicion would not tend to point towards AudioSession even if it has just been deprecated. It would be very bad form to break something right at the time of deprecating it that all audio code depends on, and really out of character.
• The entire reason OpenEars never used VPIO is because it has broken in one x.0 OS version and one minor version I can think of off the top of my head (it could have happened with more but since I stopped using it, I stopped testing it), while remoteIO has always behaved the same. So my suspicion would tend to gravitate towards VPIO at the time of a known-to-be-high-pressure x.0 release because there seems to be some kind of minor hole in the API’s testbed where VPIO behavior sometimes changes between releases and then gets fixed.
• It may not be necessary for you to use VPIO with OpenEars >=1.5.x because it has a new audio modes API if you’re supporting 5.0 or greater. It’s controlled via PocketsphinxController so it might be worth a look.