I've seen a few systems try to add this sort of completion preview to editing, and it seems to mostly be based on (ultra-common) mobile device autocomplete UI. The problem with bringing that model into an editor is that mobile device autocomplete is about helping users *append* text to the *end* of a very small chunk of editable text. Those systems also have various ways to "move the cursor", and they're uniformly considered worse, because the interaction model is a bad fit for the user affordances.

I've seen a few systems that add this sort of in-line expansion suggestion to actual text editors, where most of the editing happens in the middle, not the end, and the jumpiness that results is, well, it's usually not considered good. (The flashing/updating you get just from adapting the code highlighting to such systems is jarring enough that most editors add extra layers to mitigate it.) I don't know if it's accidental or intentional, but I believe this sort of problem is why you almost always see examples demonstrate mid-text suggestions via pop-ups, and in-line suggestions nearly always demonstrated (as in this screenshot), at the end. 

Put another way: there are strong reasons to consider Eli's suggestion that Emacs grow/evolve infrastructure to display such suggestions using UI methods beyond "just insert some specially-marked text", even if some users will be happy to have the text quickly/easily plopped directly into the buffer.

As usual, I hope this helps,

~Chad