Welcome,
I think this would be unlikely to work (or unlikely to always work the same on every device and OS), because OpenEars has to change the session category in order to begin but not vice versa. That is, while the audio is compatible with both its preferred category and OpenEars’ category so it wouldn’t need to change the category if started during a listening session, OpenEars is not compatible with the audio’s preferred category, requiring a session restart that can interrupt playback. Regretfully, this is an OS implementation detail rather than an OpenEars implementation detail (audio session isn’t a very deeply specified API), meaning that it is unlikely that the same thing happens identically even from OS version to OS version so it would be challenging to try to control these kinds of results from OpenEars. Issues with audio coexistence are covered in more detail in the support FAQ, but generally, I’m sorry that it isn’t possible to cover every case like this.