This is, of course, right, but two-way sync (in both directions) is possible nonetheless (albeit in a way that's quite fragile). Here's the rough idea (both requiring that pdfsync be used when compiling the .pdf file):

1. For backward search (from .pdf to .md): have the .pdf viewer send the source (.tex) file and line number to a script that (a) reads in the relevant line from the .tex file, (b) extracts a reasonable-sized chunk of text, (c) searches for that text in the corresponding markdown file, and finally (d) sends the line number of that text to the text editor.

2. For forward search (from .md to .pdf) do the opposite: have the text editor send the source (.md) file and line number to a script that (a) reads in the relevant line from the .md file, (b) extracts a reasonable-sized chunk of text, (c) searches for that text in the corresponding .tex file, and finally (d) sends the line number of that text to the .pdf viewer.

Clearly, a problem lies in step (b) in both cases: how do you locate the relevant text to use in searching the corresponding file for? What I've done differs between (1) and (2).

In (2), I find it easiest to take the whole line of markdown, strip off any initial markdown codes (such as those for enumerated lists), run it through pandoc (using exactly the same options I use to generate the .pdf in the first place) to convert to LaTeX, and then search for this in the .tex file.

In (1), I find I need to use a different strategy, since .tex -> .md conversion in pandoc often fails to produce a match in the .md file. (This is partly because of the way I have extended markdown using some filters.) So here I try to locate a stretch of text in the .tex file that does not contain any LaTeX commands as follows: I try searching for the first occurrence of '\' in the relevant line, and if this occurs deep enough into the text, I grab text from the beginning of the line to that point. If not, I look for a stretch of text after that '\' that occurs between '{' and '}'. Usually this is good enough to find a unique match in the markdown file.

As I said, this is fragile: it won't work in every case, but for me it works about 90-95% of the time, which is good enough for my purposes.