Regarding round-trip editing and such, there are a bounty of existing discussions on this matter, here are a few:
- Round-tripping from Scrivener-to-Word-and-Back ?
- Export → Process/Edit → Import (ideally retaining binder layout and styles)
- Editor Use Case
I’m very much the same way, and as someone else posted, I think most of us are. You form blind spots that are unique to the working environment, and removing your work from that environment greatly aids in spotting them (I even do that for my forum posts—I’m typing this up in a Markdown editor, but I’ll be proofing it using the forum’s preview). My own approach is to compile to the end format, and generally in a form I can’t edit. Its only purpose is to divorce the content from the original environment. For me, that’s PDF. I drop the PDF into my Project Bookmarks list, and when I’m ready to proof, I drag from the bookmark list into my split editor’s header bar, which views it straight off the disk (no need to import and clutter up the project with proofing copies). See below for tips on making this PDF a better proofing tool with links back to Scrivener, within it.
Now I can continually compile back over that PDF file as I work, and refresh the PDF viewer in the other split. It’s easy—and I’m making my revisions in Scrivener, not some other program/file entirely that I have to tear my hair out attempting to reintegrate. For me that would be very difficult because my workflow involves starting with something that does not in any way resemble the output at any level. Since I always compile proofing copies to the same folder, with the same file name, that project bookmark remains valid and convenient for starting a proofing session. You dont even need the project bookmark though, if you prefer sequencing proofing copies with a date stamp or something, then just drag the PDF into the editor header bar from the system to view it without importing it.
That’s how I do it, but there are many other ways, and if editable text works best for you, I’d still encourage using it as-if it were read-only. The main benefit we’re looking for after all is that context shift. We don’t need to edit in the content shift copy to get all of the benefits of it. I like using Scrivener’s splits because I can PageDn the other editor while editing in the main split—but multiple program windows side by side also work. There is no one right way here. Some prefer using ebook reader software and epub output, which has the benefit of being able to read from a more comfortable environment, and jot down problems using the reader software’s annotation features.
Please don’t. 
A few searches should reveal that’s already been asked for, and here is the best answer as to why that is, conceptually speaking, not even just technically, extremely difficult.
The feature I believe @gr is referring to is more passive than that. There is a setting in the compiler (Insert links back to Scrivener in each section) that will insert special URLs into the document that link directly back to the binder item used to generate the section following that link. Open the compiled document in Word, Ctrl-click (or whatever you need to activate a hyperlink) and your project will open up, if necessary, and load that section.
There is a secondary option below that, Insert unique document identifiers only, that inserts a plain-text code into the output. These are uglier, though more robust in that they won’t get cleaned out by security mechanisms or otherwise damaged when edited in tools that don’t understand Scrivener’s links. When a document containing these markers is imported back into the binder, it will not be split by them, back into the original items because that is unsafe (for the reasons given in the linked post above), but the markers will be turned into native internal links to greatly ease incorporating revisions. Open the imported reference into one split, and by default clicking links opens the original in the other split.
As an aside, stemming from that setting, you can see we do not recommend never importing Word documents. There is a whole host of features, not just these, supporting that capability. We even built our own custom DOCX read/writer. So the suggestion one should never do that and only load up Word alongside Scrivener is a bit overkill. The main concern raised there is that some advanced feature usage in Word might “corrupt” Scrivener—honestly I’ve seen maybe two or three actual cases of that over many, many years. The risk is very low, and not difficult to revert from. And besides we’re talking about something exported from Scrivener, being edited and then brought back in. The odds of such a document being littered with advanced field codes and complicated page layout features at all is extremely minimal and trivial to avoid as you have to go well out of your way to end up with a document that includes those things. Just don’t implement an expensively designed corporate letterhead into your .docx file that you’re proofreading, right?
Lastly, as I’ve said before, the challenges of trying to get two completely different kinds of software working together on the “same source” is one of the big reasons for why many people do not consider Scrivener part of their late-phase editing workflow. If you’re banging your head against obscure bugs or simple conceptual problems that cannot be resolved, for days/weeks, then at some point you have to question whether or not it is just best to sit down in Word and use track changes. There’s no harm in that. Very few things in life can all be done with one single tool.
Some can make it work, there are good answers above and laced throughout the forum! Don’t get me wrong, I’m just saying if it is causing one frustrations there are almost always more efficient solutions that involve using the right tool for each aspect of a job.