Yup, that matches my expectation. Here is what I would guess is going on:
There are a few different iOS objects which take over the audio session and do not return it to the state it was in after they are no longer instantiated. Specifically, some of them turn off recording. So if you are responsible for an SDK that does continuous listening (e.g. both OpenEars and Nuance) you will get a lot of complaints about it ceasing to work after using AVPlayer or similar, because the iOS object removes the audio input. So you will put in a sanity check that makes sure to fix the audio session before your product does its thing.
OpenEars does its sanity check when it re-opens the audio unit so that it is possible to play video while speech recognition is in suspended mode, since this is a very frequently-requested feature.
The call you make to the Nuance object above almost certainly initializes their own listeners for audio session changes, which they deal with in their own way.
I think that what you are seeing is that OpenEars is performing its sanity check before it tries to open its audio unit, discovers that Nuance has changed the audio session, fixes it, and Nuance discovers that OpenEars has changed the audio session, fixes it, comedy ensues.
I can’t speculate about why it’s only happening with iOS6 but it could easily be a race condition that was always there but was resolving differently in iOS5.