Im for the included support of 24,32 bit samples.

Obviously that's the long-term solution that everyone wants, however the design decision needed here is if we need to jump through these hoops or if there is another acceptabe short-term solution for the 1.24 release. And no, you don't need to answer that question, this ticket was not created to gather user opinions.

In this case, sorry.

But it woudn't be an bad idea if the first idea is considered that OpenMPT lets the user chose if he/she wants the file normalized or not and then creates an temporary copy (similiar to how virtual memory works) that is getting edited instead of the original file on the harddrive. The user can chose whenever the original file can be overwriten (if changes were made at all), or an copy is made from the temporary file and the links point to it instead of the original file.

Might work and solve that tricky problem you're describing :).
And i hope there is finaly gonna be 24,32bit sample support for real.

For now, an alternative short-term solution has been introduced in r4633: When a sample gets normalized upon loading, the "sample modified" flag is being set automatically. This way, the user is prompted to save the changes when closing the module anyway.