I’m not sure how this has an impact on what you are describing, but that isn’t how the Mac editing component works at all. You can try it—load up something with a bunch of text you don’t mind accidentally damaging, and scroll while pounding on the ‘d’ key. It’s all live—there are no modes.
That aside, I still don’t understand the nature of what improves with your suggestion, over what we already have. Pardon me if I misread, but I feel you dismissed my entire argument with the offhand statement “First of all, I wouldn’t suggest a new functionality for Scrivener if it already existed.” Granted, but my point was perhaps not understood, so I’ll break it down:
- What you are have suggested is something that has been suggested before.
- The current system we have now is a direct response to what you are suggesting.
- Hence, in what way do we have it wrong?
These are constructive points and questions toward your ruminations: what could be improved about the current system that does not diminish its current flexibility and power, that would make it more like what you are thinking of?
Articulate what advantage there would be in binding note presentation to the current scroll view. I can think of some, but maybe I don’t understand well enough what you have in mind—because to my mind, the following advantages of an independent scroll view for notes outweigh any of the benefits supplied by binding note scroll views to the anchor text, by any means or form of presentation:
- The ability to see notes outside of their context. If I’m looking for a figure that needs work in Photoshop and I’ve tagged it in a previous editing sweep, I can see it at a glance in the sidebar, click on it, and be taken straight to the image.
- The presence of that metadata—the awareness that one gains by looking at a note that reminds them of Photoshop work, is something I acquire no matter what portion of this text I’m working on. With the fixed attachment model I must scroll the viewer to the very figure itself before I am made aware of the need for fixes.
- The ability to jump from one note to another by kind. Using colour or other text-based markings, I can readily identify a sequence of non-linear notes that pertain to a thread of edits or thoughts—whatever I need of such a capability—and leap frog through the source text by that particular strain. I can even do this with the arrow keys when the focus is in the comments pane.
- Because of some of these capabilities, our comment system can be used to go beyond mere comments. They can serve as a bookmarking system, an object referencing system (mark all tables in orange, all figures in red) and so on.
- The many advantages I listed in my prior message that haven’t been remarked upon in your response:
[list][*] Lack of constraints in note size to body text ratio.
- Decreased lack of constraints in note density to body text density ratio.
[/*:m][/list:u]
You might say it is possible to have both—I think Word does in fact, have a stacked comment viewer along with the spatial marginal model. Yeah—one can do that—but I feel there should be a very strong advantage to having such a duplication in the feature set. To my mind, word processors that have a subsidiary stacked viewer somewhere hidden are basically just responding to the limitations and weaknesses of the strict marginalia approach—it’s a concession. Scrivener cuts out the fat and just provides the interface that works simply and elegantly.
And to be clear about another thing, I am very well aware of the counter-cases where some of the above aren’t desirable. I for one am a very strong proponent in surface layer notation that cannot be easily avoided, and notes that are obscured by the bulk of the text they pertain to, rather than being omnipresent. That is why I myself use a huge mix of inline annotation and sidebar comments. I use the sidebar when the above advantages of very much desired, and I use inline footnotes when I want notation and text to be very tightly coupled.
Would I prefer inline notation off to the side? To be honest, and rather emphatically, no. 
I like being able to use the full editor width for my notes—the same formatting context you might say. I like being able to type as much as I want. I like being able to slip in and out of notation while writing with no more friction than can be had slipping in and out of italics while typing. I never have to reach for the mouse to switch columns are text controls. I never have to click on a tiny triangle to open a bubble. I very much like that anchor text can become notation with a simple toggle and vice versa. And after around twenty years of using various inline notation mechanisms and implementations, I have no problem at all reading around them, either.
So from where I sit: margin notes would be a downgrade for either inline notes or comments as they currently stand. If one system were to replace both, and all of the necessary design, development and testing that goes into such an endeavour would embarked upon, I would hope at a very minimum that the result would not be less than what was started with.
So—again, I must ask, “…what material advantages are gained by pinning a comment’s text into the surface area of the editor, anchoring it visually to the text it relates to, and constraining its overall shape and size by the limitations of the area of the text that defines its context?”
This isn’t a hyperbolic defense of what exists. This isn’t a shut down. This is a conversation. That’s what we do around here. We talk about ideas, and sometimes these discussions lead to material gains in the software.