I mentioned using pandoc to lint, and since you mentioned the collaboration part happens with docx, I am thinking about a linting method that I haven’t tried so far:
What I’ve tried: pandoc -f markdown -t markdown ... as a linter (internally: markdown to AST to markdown). In my use, this works quite well. Technically, you’ll want the “linted” version to be “stable” (meaning that a 2nd lint would change it at all). i.e. idempotent. In my test, it seems that repeating the above steps twice will give you a stable, linted document.
[Just to emphasize it again: @jgm said that pandoc is not designed as a linter (albeit it is very good at it). i.e. any imperfectness in linting is not a bug per se.]
Since in the end you want to “merge” the docx back to your markdown source, you’d want to pandoc -f docx -t markdown ... in the end. However, even if your colleagues haven’t changed anything, this step will still gives you a lot of diff.
So the way to lint the markdown before sharing first is kind of like pandoc -f markdown -t docx ... | pandoc -f docx -t markdown ... applied on your markdown. This is kind of like the one above, but more conversions happened, because internally: markdown to AST to docx to AST to markdown. But I suspect running this command a no. of times (say, 2) will give you a stable, linted document. (Meaning that if the docx shared is unmodified, the markdown you get back from the docx to markdown conversion should not be changed too.)
Then let say you manage your markdown in git, you can have commits that is editing, linting, and “merging” (from the docx you share). That would make the history quite clear, and minimize the impact that your colleagues are not really editing the source (the whole workflow can be semi-automatic, e.g. by keeping the commands in a makefile).