The behaviour is correct: The filter is only supposed to be turned of if the cutoff is 127 and resonance is 0. That's how Impulse Tracker does but not how older versions of MPT did it. It has been the default behaviour since OpenMPT 1.20 for IT files. However, when importing songs made with older (Open)MPT versions, or when using the MPTM format, the legacy behaviour may be used instead. You can download older OpenMPT builds from https://download.openmpt.org/archive/openmpt/ (e.g. OpenMPT 1.23) and you will hear that they behave exactly the same on this specific file.

This is weird, I swear the "wrong" sound has just happened with a recent version, not something from years ago.
Is there a simple solution to retain ZBF as my "reset" command then, combining it with a resonance command? Macros have always been a little black box for me and I was happy to have found this setup that did the job.

This is weird, I swear the "wrong" sound has just happened with a recent version, not something from years ago.

That's possible if you were e.g. using an old song as a template, because OpenMPT will generally try to keep playing modules like the version the file was created with would play it.

Is there a simple solution to retain ZBF as my "reset" command then, combining it with a resonance command?

Yes, this should be helpful with manually crafting macros: https://wiki.openmpt.org/Manual:_Zxx_Macros

So to reset the filter resonance, append F0F00100 to your macro. Note that depending on the situation, it can also make more sense to set an instrument's default cutoff and resonance to 127 and 0 respectively. This is more compatible with some players that don't implement a fully macro interpreter (I think XMPlay is among those).

There is one more caveat though that you may not be aware of if you were using the legacy filter mode all the time: With IT-compatible filters it's impossible to turn off the filter for a playing note, and setting the resonance 0 if the cutoff is already at 127 doesn't do anything to the current note's filter (that's not a bug, just what IT is doing :). Only the next note played on that channel will play with the filter disabled.

it's impossible to turn off the filter for a playing note

This seems to be the problem, I assume. I have used the F0F0007F macro to basically reset the filter on a new note, just as it was playing. Putting the macro with the added resonance command one row above does fix the issue, but that ofc means I have to change the modules. Is there a simple solution to get at least the playback to my "used" state? Like e.g. an older version of MPT or some compatibility settings? Thanks in advance.

I really cannot recommend you turning off the compatibility flag when writing in IT format because OpenMPT will be the only player interpreting the module that way. Any other IT-compatible software will play it the way Impulse Tracker would. In the MPTM format however you are free to disable the Compatibility Setting "User IT’s filter coefficients (unless extended filter range is used) and behaviour". In fact, if you create a new MPTM file this setting is disabled by default, so maybe you were already working with MPTM files before when encountering the different behaviour?

I was always using .it files ever since I've been started using MPT. That may have been the first bad choice to begin with. :D
The new behaviour on the C64-like tunes just recently catched my ear and I thought it was a version error, being fixed with the next release. To be honest, it would already be nice just to render the tunes the way I made them, for preservation (it's an old project I will never finish, hands down), so playback in other players is no big deal for me. So what would I need to do to recreate the sound I've been used to? The filter coefficient setting won't fix the issue for me, even after switching to a MPTM file. Again, the sheer probem seems to be the moment the macro comes in effect. On note play as in my original module or 1 row afterwards as it is now (and, apparently, the correct way IT would play it).

If you think that a specific tune plays differently than it used to, please provide that tune (you can add a private note in case it's not supposed to be spread), because the example file provided definitely isn't affected by any recent changes. It's always possible that there's a bug that affects a "real" song, though, that isn't expressed by this particular example (as mentioned, I did verify that it plays exactly the same in older versions).

The filter coefficient setting won't fix the issue for me, even after switching to a MPTM file.

Just to make sure, you turned the setting off, correct? If the setting is turned off, it should absolutely behave the same with all OpenMPT versions because that code path should be essentially unmodified for the last ten years.

Just to make sure, you turned the setting off, correct?
Yes, No change in sound whatsoever.
I've added one of the unfinished tracks in which the change was most noticable for me. The kick on channel 3 in the second pattern was playing unfiltered with my ZBF in a fairly recent version. Strangely, it is now playing unfiltered on the fourth beat and I really don't know why.

Thanks for the example file. This was introduced in r12932 / OpenMPT 1.29.02.00 as a side effect of fixing another edge case. Guess I'll have to find a more clever way to fix it... For the record, Impulse Tracker would also turn off the filter in your track.

In fact, r12932 did break another already existing test case (really looking forward to that not happening anymore once 0001507 is in place...). r16016 now fixes both that test case and your module. Test builds will be available in a few hours from https://builds.openmpt.org/builds/ and of course the fix will be in the next stable OpenMPT version.