To your confusion around PlayOneShot vs EventInstance - you can use PlayOneShot in tandem with creating and managing your own instances, it’s simply about what you’re using each of them for. Managing your own events gives you a lot of freedom with how you approach audio implementation, but requires you to potentially be managing a reference to them, updating parameters and 3D attributes, doing garbage collection, etc. PlayOneShot and PlayOneShotAttached are useful when playing audio that you don’t want to actively manage, which reduces the amount of coding you need to do.
To paraphrase what Cameron said in the thread you linked, StudioEventEmitters were designed to handle single events and to be an example of directly interacting with the API yourself once you’ve outgrown them, however they’ve had more and more functionality added to them over time.
Besides the fact that you’re effectively creating your own fork of a StudioEventEmitter by modifying it, there’s nothing wrong with using them as you’ve described - much of the more “complex” functionality that a StudioEventEmitter can’t handle itself can be achieved by using your own scripts in parallel, and accessing its public fields as you need them.
You can definitely implement a similarly solution for your game without using StudioEventEmitter - you can replicate your “one emitter to one audio context” structure by keeping a reference to an EventInstance for each audio context instead. Obviously, it’ll take a little more coding since you’re handling a lot of what a StudioEventEmitter does manually, but the StudioEventEmitter script itself as well as basic Unity script example in our docs are good references, and you’ll have a lot more freedom to customize the behavior of your audio.