Now I am curious if this can be seen as coding in a bad behaviour?
TL;DR + IMHO + AFAIK: You’re fine, because SonicPi is about play. But at some point you might become frustrated by unexpected behavior. Until then, however, play around - because you might also become happily surprised by the unexpected behavior!
So, if I read the SonicPi docs correctly, then it’s not that SonicPi prevents race conditions, it’s that it makes them repeatable; so I’d say the answer to your question is “sort of”.
Mutating (changing) global state like you want to do means that you, as the programmer, cannot be sure what that state is at any point during your program, and thus can’t be sure what your program will do, overall. This is part of what it means to have “race conditions” in your code.
However, in SonicPi, this is (AFAIK) fine, and since SonicPi handles race conditions by making them repeatable - in other words, although you as the programmer cannot know what will happen, you can just try it, and if you like the result, it can keep happening.
To put it another way - Race conditions mean that each time you run your code, something different might happen, without you having changed anything. In SonicPi, however, unless you change your code, the same thing will definitely happen each time you run your code.
However however, you may run into an issue where you like what’s happening, but in the course of changing the code, you might affect the timing between what’s updating
q and what’s reading
q, and thus change what happens. This is where you might be frustrated, and if you get here, you would then want to consider other ways of doing what you’re trying to do with