Also -- is the filename template supposed to be user-editable?

I'd rather say it's maybe a communication issue of the template display than an implementation issue. Due to how autosave versioning management works, the full filename needs to come first, as the cleanup code essentially just iterates over all filename.Autosave.* files. If filename didn't contain the extension, it would iterate over autosaves from both filename.xm and filename.it. And the extension at the end is just to keep the file easily open-able through Windows file associations.

I'd rather change the example filename shown in the UI than changing the cleanup logic.

Also -- is the filename template supposed to be user-editable?

It probably maybe was the intention some 16-17 years ago to allow for that, but no, the template is fixed and never was editable.

Slight correction -- I believe it's manually-initiated backup, rather than periodic autosaves, where I'm seeing this issue.

If you refer to the "create backup copy when saving module", that always creates a backup by replacing the module file extension with .bak. The autosave template does not affect that option. Note that also due to how MFC works, no file extension is included in the autosave filename pattern when autosaving a yet-unsaved file.

Nope, I guess manually-initiated backups only ever swap the extension out for .bak -- which I guess wouldn't work so well for your filename.xm versus filename.it example scenario :)

which I guess wouldn't work so well for your filename.xm versus filename.it example scenario :)

There is no automatic housekeeping of .bak files.

True, but one file's backup could overwrite the other file's backup, which might be bad. :shrug:

Well, it's important to keep in mind that the features work quite differently: .bak files are mostly intended for being able to rescue the exact previous version that you maybe accidentally just overwrote, or OpenMPT crashed while writing the file, or whatever - i.e. generally there is a need to access this file immediately, and it's unlikely that you will have edited another file with the same name in the meantime. The file is also always guaranteed to be placed next to the original file, so filename.xm and filename.it would have had to be stored in the same folder to begin with.

Autosaves, however, accumulate over a longer period of time, and depending on settings will all be saved in one central folder. Because of that, being able to tell the source files apart is a bit more relevant. But in the end, extending the backup mechanism to always just append .bak instead of replacing the file extension could make sense though. that would be the best of both worlds.

The example filename display was adjusted in r22336 along with some other changes.