A custom INI implementation should avoid this scenario. While the file is being written, other OpenMPT instances should wait until the file is no longer locked, rather than reading incomplete settings.

I do not think this would be necessary. Atomically writing the file is the easier approach, because we do not (and do not want to, and cannot) guarantee settings consistency across different instances running concurrently anyway. Writing the file in 1 go should also be plenty fast enough to avoid the mentioned race condition. If the second instance is started while the first one is still actively running, there is not much we can do anyway, except for maybe flushing the configuration file after the welcome dialog (which would probably be a good idea even with the old implementation).

There are a couple of open questions regarding our own implementation:

1. Do we want to handle binary data in string data and key names properly? Windows INI parsers do random confusing and undocumented things here, mostly stripping unwanted characters and trimming the result.
2. Do we want to preserve ordering of the INI file as read from disk, or do we want to canonicalize/sort what we write out?
3. Should the format be strictly backward compatible with the Windows INI parser, mimicing all its undocumented quirks?
4. How to handle duplicate entries? (I did not look into how the Windows INI parser handles this)

The INI implementation that I have in an older code base answers these questions as:

1. escape both key and value data
2. strictly sorted output, preserving comments to the respective entry on a best effort basis
3. no, because of 1 and 2
4. I have not looked into that in detail yet.

In case the answer to 3 is "no", we should use a different file name in order to not break downgrades completely. "OpenMPT.ini" would make sense here.