Sam is mostly right, though the “embarrassingly and completely” part was maybe a little exaggerated.
The limitations are well documented, you’ve recapped most of them in this thread. It works well for simple text content and quickly degrades when disparity exists between the relative height of elements between Markdown and Preview views (eg. tall images, or embedded content).
There are a lot of ways of looking at solving the basic issues - the oldest open PR on Ghost is in fact to improve the scrollsync based on proportional scrolling whenever an image is detected. It works - kind of - but not reliably.
I’ve seen many attempts at solving this problem since we launched Ghost, but the best by far that I’ve seen is the one already mentioned above: StackEdit.io - which is fantastic on so many levels, and open source (MIT if memory serves).
But - the real question of course has little to do with which implementation is “best” and far more to do with which implementation is “right” for Discourse. In that context my humble opinion would be that you can try to perfect this feature until the proverbial cows come home - but what you actually have is 2 very simple, 200px high, textareas which are largely used for straightforward text content.
One thing worth noting is that Ghost deliberately only triggers the sync function if you scroll in the left hand pane, while the right hand pane can be scrolled freely and independently. This way, if and when the scrollsync ever does do a poor job, the user is never “stuck” - but can at least sync manually as a plan B.
Good luck, whatever you decide - and my apologies for offending Sam with my hacky ways. It was a day where we simply needed to get the job done and ship