I don't think this rises to the level of awfulness that Mamesick sometimes likes to perpetrate. At least the results are correct and pretty good looking, which I can't say for several Mamesick specials.
That said, this does clearly belong in the core as an optional attribute of screens that are type LCD.
ETA: Regarding tuning, I'm thinking you pass a struct that specifies how many frames to involve in the persistence and how much each contributes to the final image. It could be fiddly to tune, but you need that power.
Also, doing it in the core opens up the eventual possibility of having a pixel shader do it for you, which would be an obvious performance win.
There is a certain irony in the whole situation, that being the very first thing I ever did with MAME was release a couple of hacked builds which simulated an LCD screen for the output, by combining various amounts of the previous 2 screens. Of course, not having a clue how anything worked back then I destroyed all the normal output in the process, so it wasn't optional, but it was all good fun ;-) I mainly did it at the time as an example showing that it could be done and looked good, because none of the handheld emus had such a feature, and it was annoying me.
The pre-Aaron MAME D3D code actually had a 'feedback' option which could be used to give a similar effect, but it was ripped out along with everything else when Aaron added his own D3D implementation.
