The basic issue with audio is that we do not support every format under the sun, only some very specific formats that we know we can play on particular platforms - this is why we do not allow you to load any sounds at runtime as we know from experience that we will get lots of complaints of the form (audio does not work because my sound does not play) - we get this now as some WAV formats fail to convert correctly.
We are addressing this by improving the converter and ensuring that all sounds are in the correct final formats for the target platforms.
We cannot unload the sounds as basically that will just create holes in memory which will not get reclaimed as resources in the main game cannot be unloaded.
In the long term GM:Next time frame we are planning to allow multiple resource files to be created so that resources can be dynamically loaded and unloaded from memory - but this will not happen until the runner and compiler have an architectural overhaul as this cannot be accomplished without it.
Russell
Man, I can see how much trouble it would be to deal with those "bug" reports, but at the same time you're taking useful functionality away from people who WOULD know how to use it properly. I'm sure it's a lot more complicated than that, there's probably a lot more that would need to changed behind the scenes to allow it... but if the biggest issue with giving us the ability to load resources at runtime is just that people won't do it right, why not emphasize how to do it right? If someone tries to load an unsupported format, have GM throw a specific error message like "Audio format unsupported. Please use WAV, MP3 or OGG."
Again, I'm sure it's nowhere near that simple of an issue, but from my limited understanding it seems like a lot of things are getting dropped simply because they're not relevant for more than one platform or would be difficult to utilize correctly without a proper understanding. And while I can understand prioritizing major stuff like shaders, a new debugger and an improved compiler over trivial things like CD tray functionality, I don't see the point in intentionally removing functionality unless it's been obsoleted due to technical reasons, like the room transitions and message functions.
I'd gladly accept a greater emphasis on/enforcement of good coding and development practices if it means a much larger degree of functionality, even if some of that functionality is only useful in very specific scenarios. I'd much prefer that over a tool that's mistake-proof but limited as heck.
Keep your butter knife... make me wear the safety gear and then give me that chainsaw. 
EDIT: Wait, I just re-read your post -- you're saying that audio resources created by loading files at runtime will create memory leaks? And fixing that would require completely re-writing the runner and compiler so they can essentially create placeholders to reserve space in memory for dynamically-loaded sound?
If that's what you meant, then that's a very valid technical reason which pretty much renders my whole argument pointless... so, uh, my bad! 
Edited by Mack151, 13 May 2013 - 05:12 AM.
