Yes, that's what surprised me. There's probably few drivers that do this, it appears the code was added long before HLSL was introduced, and has since stuck around.
First, i am sorry that i couldnt reply to your PM, but real life caught me

. I am very happy and proud of you, that you solved this at a decent speed and it proves that some stuff could be solved pretty fast.
Second, i dont want to start any flame war on the devs or conspiracy, what devs do and what not. Its their baby and they can do whatever they want with it. My intention is just to inform you all, that maybe in the future, we cant only rely on the CRT-drivers alone. I think the only "good" way, would be that guys like intealls and Calamity offer their help to the MAME devs (in a regular schedule) to solve CRT critical stuff. Maybe even invent a new function/switch, that could turn on/off such things.
Like i said, they did the frame-blending to avoid flicker on LCD/LED, at least that was told to me. I am really suprised, that this stuff was made "long before HLSL was introduced". The main point is, that devs dont bother with CRT anymore. None of them have one during the development and it would be wrong of us, to blame them for that reason. Its far better to help them.... with skill

.
They said themselves that it is to time-consuming to mantain CRT support, so its our duty to keep that alive. I am no coder or have your skills, but i am a very good observer (thats why i co-op well with Jezze and test any new changes on HLSL), have enough knowledge to identify a problem and have enough real hardware to compare vs. emulation. Thats the things i can offer.
It would be interesting to see, what intealls patch brings us. Someone should compare this and tell us the result, as I am not able to do this at the moment.
Anyway, big thanks to intealls for taking the time to solve this and taking the "problem" serious enough. I am pretty sure, we will be confronted with more stuff like this in the future.