I think you’re over complicating it. What you really want is just a real-time spin lock around your currentSound and make sure you only ever call tryLock on the real-time thread. If this fails, it means your non-real-time thread is currently assigning a new sound and you’ll have to render without the sound.
@timur wrote about this in great detail recently with an almost identical use case: https://timur.audio/using-locks-in-real-time-audio-processing-safely
The only other thing I would say is to try and avoid getting in to this case in the first place.
In general, if you can make your render graph rebuild when something like a sound file changes you never end up in this situation as you just have a root node to process that you can swap atomically.