After further testing (and some experimentation with a patch to convert soundsource::manager to inherit events::pump_monitor), it seems I was mistaken about a few things:

- The affected sources all had the loop attribute unspecified (defaulting to zero), which theoretically means (if the wiki were to be treated as a source of accurate information, which it is not) that the sound should only place once until the player scrolls away and back to the specified location; sort of like and incredibly large value for the delay attribute.

- However, the loop attribute does not work that way in practice when set to zero. It only means that ONE of the chosen sound files from a list will be played exactly once rather than being looped for the duration of the sound source's effect. As a side-effect, no new sound will be chosen while GUI1 or GUI2 dialogs are running. The rest of the time, however, it will continue looping on the chosen file.

- If the loop attribute is set to -1, the game will pick one of the given files in a list, and play the same sound forever for as long as the sound source is active, even when GUI1 or GUI2 dialogs are running.

A test case in mainline already exists in the test scenario; you can check its unique sound source's behavior when the loop attribute is set to -1 (as it already is) or 0.

This is all very confusing and suggests that I'm trying to implement a feature that already exists but is just broken or incorrectly designed. I'm leaning towards the latter.