Just that it's changing the frame rate with multiple tricks to achieve the output, and so the output frame rate isn't even correlating to what the input frame rate was. In fact the output with the blurring and other LCD issues is a lot like compressed video and what the non-frame rate temporal types of compression tend to do. So it can fudge and change around the output framerate to make it work, put an extra frame here and there to make it fit and smooth it out between frames to avoid tearing, instead it's sort of blurry.
Not really. There is no "between frames". If your LCD is fixed at 60fps then that's how many unique frames it can show in one second. Those are your allotted time slots, and while you can fiddle with what you're going to put in each one, you can't put anything between or around them. In other words, the time dimension or time granularity is locked, you only have 2 space dimensions left to work with.
So, if you want to apply this extra step, you first need to realize it will only affect the space, not time dimension. "Motion interpolation" effect comes 'on top' of whatever you have done with frame rate conversion first, and to implement it you will need to double display refresh rate (or triple, or quadruple), i.e. increase the number of alloted time slots so you can put those extra frames in.
There are two problems with it:
1.) This is intended for TVs where standard frame rate conversion produces hiccups and judder which is closely spaced in time, but the choppiness produced with small mismatch in frame rates, like Galaga +0.606 or Moon Patrol -3 frames per second, produce choppiness that is just too sparse, it falls out of the limit where it can be smoothed, not even if you insert 100x more frames in between.
Once you drop a frame you practically change the speed of all the objects in the scene for that instant in time. Interpolation can't quite "fix" that, it can only make the animation of it all more "pleasing" to the eye, but even if it's all "blurry" you will still notice all the objects increased their speed and then suddenly slowed down back to normal for no apparent reason, your brain will know that's not what actually happened, but it's only ugly visual artifact known as "telecine judder".
2.) It takes time to do this interpolation, it produces latency aka lag. By the way that example from above looks too good, I don't see how can image algorithm possibly make it look so perfect. In reality it's more like this:

In any case that explains "ghosting" a bit more clearly. So, we did our frame rate conversion and we now have exactly 60 frames to match with our fixed 60fps LCD, all together with hiccups and judder. Now we press the "smooth" button and this doubles our display refresh rate to 120fps. In ever 'even' numbered time slot we place original frame and in every 'odd' time slot we place our intermediate frame. But, to produce this extra frame we need to have the next frame as well, since we need to combine these two to make our "transition frame". This means the display must be in the past, lagging behind the real time for at least one frame, which is still at least ~17ms even though we now operate at internal 120Hz.
If you really wanted to "smooth" sparse judder where there is a small mismatch in refresh rate, you will need to combine not two frames, but as many frames as there is in between each hiccup. Galaga's 60.606fps would produce hiccup only once every two seconds, so you will really need to buffer and interpolate 121 frames, which means 2 second latency, and that's just out of the question. In more practical view, the problem here is that this does not seem to scale so that we are be able to compensate latency for quality, so I think choosing the tearing over judder and "smoothing" that artifact instead might be easier and more effective than smoothing judder, but I don't think anyone is actually doing this in practice.
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course.
Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?
It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.
So how does the smooth mame patch then have the ability to change the original framerate? I've always thought about it like sampling analog, or the actual video camera, and at the mame emulation end feeding the frames, the source basically, can alter this in multiple ways just like feeding an encoder or monitor/LCD. I'm not sure how correct I am in assuming that, I do know in cases like the redraw patch of cabmame it is exactly like that in doubling the framerate through repeating each frame twice. I've just never fully known if it really is at the ROM/machine level that we could have the ability to alter this much at all or that any changes like in smooth mame are going to be doing some loss/add to what the ROM/machine is giving out. I guess in smoothmame it's changing the machine, at least I am guessing, to run at a different pace, and is it really true that the ROM can just alter if the machine is altered like that, in what the output framerate is? I guess since smoothmame works well on an LCD, it must be doing something right, just wondering what the technical reasons are for that, how it really is allowed to alter the fps or Hz, and yet the LCD can't do it right at that later stage in the pipeline.
As kirck said. Imagine there is no emulation and you already have all the frames ready, say recorded and saved as a collection of images: frame_001.bmp, frame_002.bmp, frame_003.bmp... and so on. Imagine you recorded Moon Patrol at 57fps, and now if you play-back those images at 60fps it will perfectly sync with the 60fps display refresh rate, but everything will be slightly faster. Speeding up or slowing down is regularly done as a part of "telecine" process, not only on its own but also in combination with "pulldown" techniques aka skipping/repeating frames. Changing speed, that is the only one of these telecine methods that leaves the frames as they were, the only good looking one.