That sounds like OpenMPT is autosaving the song (and any other songs that might be open at the same time) - although in that case, audio playback should continue, only interaction with the GUI should be blocked. Do you observe a similar delay when manually saving the same file?

Yes, it does occur when saving, and (now that you mention it) if the song is playing when the tracker freezes, the song continues to play in the background. I should also probably mention that when OpenMPT freezes, usually the application is marked as "(Not Responding)", which, if you start clicking or pressing buttons, can lead to a full-on crash.

which, if you start clicking or pressing buttons, can lead to a full-on crash.

That's not a crash. When Windows shows you the "not responding" dialog, you can choose not to click on anything and wait until it becomes responsive again. Just let it sit there until it is done saving. However, it's quite surprising that you even see that dialog popping up with just a few dozen instruments. How many megabytes of sample data are we talking about here, and and how many VST plugins, if any? Are you saving to a spinning hard disk or SSD, or even worse, maybe a thumb drive? Does turning off sample compression help?

Forgive my ignorance; I'm not really sure how to easily find the amount of sample data, since all of my instruments are .sfz files pulling their samples from various folders.
No VST plugins; only two DirectX Media plugins.
I believe my laptop uses an SSD.
I just changed the sample compression to 7 and 6, as recommended in that forum post.

Forgive my ignorance; I'm not really sure how to easily find the amount of sample data, since all of my instruments are .sfz files pulling their samples from various folders

Just give me the size of the resulting module file - the biggest amount of that will be the samples themselves.

Assuming that you are currently working in IT format, what can help with large SFZ files is using the MPTM format instead during composition (it is a superset of IT); that way, the samples from those SFZ instruments will by default not be embeded in the module file itself but references to the original sample files will be stored instead. Once you are done with the composition, you can convert it to IT format (use the Cleanup functionality to further reduce the size and get rid of unused samples).

The module file is a hefty 476 megabytes; I tend to use the same module file and use sequences to separate my songs.
I'm actually using the MPTM format already, and do so by default.
Actually, now that you mention embedding, should I not have selected "embed all" in the dialog box that occurs after I modify soundfont instruments in OpenMPT?

I see, that is a whole truckload of samples. By setting the sample compression values from 7 to 6, you are not fixing this particular situations as you are working in the MPTM format (7 = 1+2+4, 6 = 2+4 so both values include 4 for MPTM). You would have to set the sample compression settings to 3 (for mono) and 0 (for stereo) to enable the default sample compression settings for IT files but disable it for MPTM.

If you modify the samples, there is no direct way around embedding them in the song, so "embed all" was the only sensible choice in that particular case. What I would recommend in your particular situation is a "project folder" approach: Have a dedicated folder for the MPTM file and WAV or FLAC samples to go into the same folder. You can achieve this by Shift-clicking the Save button in the sample editor to save all samples in the current module, and then choose the folder the MPTM file is located in to save them all in the same place. Then shift-click the "Keep sample data on disk" checkbox in the sample editor so that all samples are marked as external samples.

This has the advantage that samples are not saved during regular save and autosave. You only need to update the sample files when a sample is being edited from the sample editor, but OpenMPT will remind you to do so if you are about to close the song if any modifications were made. This should greatly speed up regular saving and also autosaving. Unfortunately there is no better way to do this at the moment - allowing the user to continue using OpenMPT while saving is in progress could lead to all sorts of inconsistencies during file save (imagine you are deleting a sample while the module is being saved; what is it supposed to do when it gets to saving that particular sample?). There might be improvements to this process in the future, but until we get there, I can only recommend using the project folder approach.

Well, it's something, anyhow. Thanks so much for your time and promptitude!

As a small improvement to this situation, the next OpenMPT version will display in the status bar when it's auto-saving a file, so that it's a bit clearer what is happening.