If a plugin doesn't let OpenMPT know about its parameter automation, there is absolutely nothing we can do about it, unless you can demonstrate that it works as intended with a specific plugin in another DAW.

Yes, mostly of them works fine in other DAW's.

Then please provide an example of a plugin that you think should be reporting its automation to OpenMPT, because I cannot just go out there and download random plugins until I find one that doesn't work.

Lasts I tried and remember are plugins from https://senderspike.wordpress.com/2019/11/12/downloads/

Recording automation from the first plugin of that list worked just fine. Please be more specific.

Ctrl+R on, when I turning ,for example, Gain knob on VCAcomp plugin, freezes running pattern and record only PCs on first knob position

Another plugin with problems - kamioooka http://www.vst4free.com/free_vst.php?plugin=Kamioooka&id=1294

I guess these plugins must be spamming the window event queue so OpenMPT is completely stalled. I'm not sure there is much we can do, but what you can do is running the plugins through the plugin bridge. This helps with the message queue stall.

Please check if r12672 / OpenMPT 1.29.00.52 works better with those plugins. It may still not be perfect but it should be better than before.

With bridged plugins, automation works better, with unbridged plugins, record stuck on line in pattern where it started, but record knob movements in this line.

So you cannot observe any improvement in r12672 at all? That's strange, since it works pretty well with Kamioooka here.

Without bridge no changes for me.

Maybe its related with bug 0000991 and fix?

No, that was basically just a book-keeping issue where the code couldn't keep track what the active song was when a plugin was bridged. Are you implying that it used to work with exactly those plugins and the exact same hardware configuration?