We should also re-consider the charset used for .MOD because of compatibility with earlier OpenMPT versions. See discussion in 0001565 .

How would this affect saving files?
Will the strings be in UTF-8? (maybe in MPTM only?)

How would this affect saving files?

In a first step, not at all or barely. We are currently tracking the encoding used inside CSoundFile explicitly, and the encoding used to save files is determined by the saving code (either implicitly because it is the same as the internal encoding, or explicitly).

Will the strings be in UTF-8? (maybe in MPTM only?)

That's a totally separate concern. For MPTM, this requires inventing a new chunk that signals UTF8 encoding, and in particular requires the loader to handle that (which is the more difficult part, because of the order in which things are done there).

All in all, this issue requires (or is related to) a massive amount of refactoring because of the way sample names are not stored with the sample they belong to (i.e. inventing some hypothetical SampleRef class that handles the relationship better than the current code). Just replacing the current char buffers for the sample names with strings has large implications for debug build performance. We had discussed using a std::map for the names due to that in the past.

I would not consider this issue to be very important or high priority at the moment due to the various inter-dependencies related to it.