This will be more difficult than it looks on the surface.

Both previews and actual modules are handled identically with respect to deciding whether to Stop() and Start() the sound device. This is done in order to keep things consistent and easy (or easier) to understand. After all, we are still seeing occasional race conditions related to these code paths (albeit way fewer than in the past). Adding a special case for sample preview would complicate things again here.
Generally not Stop()ing and Start()ing the sound device when switching between different CSoundFile would solve this particular problem, but introduce another one: timing.
The sample-exact playback and render position must be known to various other components (in particular GUI rerawing and VST plugins). When hot-switching CSoundFile while the playback is running, we cannot know upfront the sample-exact timecode of the switch-over which would be needed in order to compensate for that. The information is of course theoretically available, but only in the audio thread itself, and cannot easily (i.e. race-free and deadlock-free) be transferred to the main thread in that particular code path (at least I currently cannot see how, without the addition of another synchronization mechanism, which would be more of a hack than a proper solution).

The issue is not unsolvable of course. However, I do think it would be better delayed until further decoupling work has been done, which would untie the timing and sample position of a particular module from the one of the playing sound device.

Another layer, let's call it PlaybackManager, which sits between CMainFrame and gpSoundDevice is what I have in mind here. I had already tried implementing this twice, but the code always ended up being even more complicated than it already is, so I ditched it again.