Change any setting and apply the [Save now] button (or without changing a setting).

I cannot reproduce this. Changing a setting and clicking "Save now" updates mptrack.ini for me.
When no setting is changed, not rewriting mptrack.ini is expected behaviour.

Save now button on Advance tab in settings does not save inmediate changes to mptrack.ini.

For changes made in other tabs, you have to apply (click the "Apply" button at the bottom) them first, in order to get them changed internally and thus saved to disk. In theory, we could have "Save now" imply "Apply", but that would result in settings which have been changed and not even a tiny bit tested be saved to disk, which could, in the worst case, result in OpenMPT not working any more even when restarted.

I would expect to overwrite or recreate the entire file every time that is used on demand.

No, it will always only rewrite the settings that actually got changed compared to what is currently stored in the file. If nothing changed, it will write nothing. Not completely regenerating the file is important in order to keep settings for older and/or newer OpenMPT versions which the version currently running does not understand (and even in some corner cases for some settings that the current version does understand but has not yet actively loaded in the current run).

Ok, I see your point. But what I am noticing is that if you want to use multiple instances of the same executable, apparently it updates mptrack.ini at exit, not when a change of setting is applied.

A brief example:
Open a song, then it is shown on recent songs list, but if you open another instance, it does not load the settings applied by the first one.

I am currently using portable mode throug UseAppDataDirectory=0.

apparently it updates mptrack.ini at exit, not when a change of setting is applied.

That is by design (see also what manx wrote regarding the Apply button).

Open a song, then it is shown on recent songs list, but if you open another instance, it does not load the settings applied by the first one.

I think it would be very wasteful (and not really required) to write the Most Recently Used list everytime a file is loaded. Just think of running OpenMPT on a very slow drive and having to wait until the settings are written just because you opened a file.
Running several instances of OpenMPT is supported in general but I don't see why these instances would have to know about each other's MRU list.

MRU List is just an example (you can try with changing the sound device settings though). With this additional aspects provided, feel free to close this issue. I will try later on a more elaborated report.

Even if we saved changed settings always immediately to mptrack.ini, this would not solve the issue at all. Settings are read from mptrack.ini basically on startup of OpenMPT (there are exceptions) and then cached internally (as loading settings on every access in the program code would be extremely slow). Thus "saving immediately" and "loading on startup" would result in very asymmetric behaviour which would be even more confusing.

Reparsing the whole mptrack.ini file on every change to it would be infeasible performance-wise.

Another theoretical possibility would be to implement explicit inter-process notification and synchronisation for settings changes (which would be a huge infrastructure effort for very little gain).

Additionally, both of these last points would require the settings infrastructure to support changing settings from the outside even at all (even in the current state, a lot of settings that you can change in the Advanced tab will not be honoured immediately and instead require a restart of OpenMPT or will be lost all together because they are cached internally elsewhere for performance reasons).

Another point to consider: Synchronizing settings immediately does not even make sense for some settings like window positions or ASIO sound device channel allocation (there are probably other examples). There are also settings which fundamentally can only be applied on program startup. Thus, such settings would need to be split from other settings in order to give a somewhat consistent impression both to the user and internally in the code.

And, even if theoretical possible, I think it would not be desirable for the reasons already explained.

With this additional aspects provided, feel free to close this issue. I will try later on a more elaborated report.

I'm closing this issue now. Closing as "no change required" instead of "won't fix" because that reason is more fitting for the originally reported issue. However, the part regarding settings synchronization of running instances should be considered won't fix for the reasons explained.