In my use case I probably need to change my app to behave like OpenEars :)
Heh :) . This is definitely an maximally-interesting API design question. One of the design goals of OpenEars is for it to generally do the right thing without configuring or selecting every option in play (there are so many areas of potential optional behavior in the whole SDK that it could become development-thwartingly twiddly for the use cases of 95% of developers if I went with the wall-o-switches approach, and impossible to give good support for), and then to operate on the basis that developers who want to customize and add new hooks can dig in and alter the source however they need to. But that also means that there should be occasional discussions about whether a default expectation is correct.
IMO, apps that positively route audio to a route other than a paired and powered-on BT audio device are probably making the wrong call because the user has done enough to indicate their intentions with the BT device when they physically switched it on, which in my understanding of user expectations says more than tapping a screen button when the devices in question have a constrained battery life. Apple’s approach covers all the bases and is clearly safest.
But the shortcoming of having the discussion here is that the only information that matters is the ultimate user experience. Do you have people you can test with and get feedback from about what they are intending when they have a BT device attached and are using your app? I find that there are sometimes surprises about what is important or an obvious default to people using the apps and what isn’t.