That is to be expected - stopping song playback completely stops any audio rendering, including plugins. I am aware that this is very different to how most DAWs operate, but it's how ModPlug Tracker always did it, and changing it isn't super simple. Eventually it would be nice to have more DAW-like behaviour in this regard.

Should playing notes in recording mode/instrument editor not re-activate rendering of VSTs then? This is how it worked in all previous versions I've tested (up to & including 1.32.00.28), the problem began to manifest only after updating to 1.32.06.00.

To clarify: I am NOT requesting that VST effects like delays keep playing after song playback is stopped. The new bug I'm referring to seems to be exclusive to the Redux plugin, which stops receiving sound from OpenMPT but only when playback is stopped after loading the plugin. As long as I don't stop playback (e.g. by pressing ESC or F8) after loading the plugin notes can be played normally and the sound goes in and out of Redux.

I think I see what's going on now. OpenMPT 1.32 contains various fixes to reporting its playback state to plugins in an objectively more correct way. In particular, this means that OpenMPT no longer claims that the DAW transport is actually in a playing state (i.e. it correctly reports that song playback is paused). Redux appears to take this as a cue that its line input should not be running, for whatever reason. The fact that internally triggering a note inside Redux causes the line input to work again, even while OpenMPT still reports that the transport is paused, indicates to me that this is clearly a Redux bug. Redux developers should be informed that some internal FX might not be working as intended when kVstTransportPlaying is not set.

To make my point even more clear, even when the line input in Redux is not working, OpenMPT is still sending audio data to the plugin even when you are playing notes in the sample editor. Redux just chooses to ignore it.

That seems right. I tested in some other DAWs and Redux indeed doesn't receive sound when the DAW's playback is stopped, even when notes are played. Still, calling an update that breaks expected behavior an "objective" improvement irritates me, no matter if a bug was what caused it to function properly in the first place.

Well, off the the Renoise forums then...

I didn't say that is an objective improvement; just that the new code is objectively more in line with how the VST API is supposed to be used, as your experiments with other DAWs confirm. Unfortunately the VST API is full with these sort of pitfalls and inconsistencies, so often a change can fix one plugin (otherwise I wouldn't have done it) and at the same time break wanted behaviour from another.