It may also be worth noting that this thread was started in 2006, and was a response to the type of annotation that existed in Scrivener at that time: purely inline. Inline annotations still exist in Scrivener, though now as a separate notation layer (as you put) to the inspector based comment list (see §18.3, Linked Notation, pg. 454 of the user manual PDF). The latter form is the implementation response to requests like this one made all of those years ago.
If you are aware of that mode of notation already, then my question would be: 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? Right now I can attach a 1,000 word comment to a one-liner stub document. While a page layout based margin note system could conceivably allow for that flexibility, I think everyone would agree the functional and visual result of that would be awkward. There are other scenarios that defeat the layout approach, such as packing fifteen notes into a single sentence, and having eighteen such densely remarked upon sentences in close proximity to one another. A non-spatial stack like ours doesn’t miss a beat—it’s designed for scalability and author-centric notation, not page-centric output.
Most word processors do work the way you describe. Footnotes are at the bottom of the physical page in a tiny font, notes are in little boxes along the margins. It’s an emulation of the constraints of paper designed for an environment that is built entirely around the constraints of paper. Scrivener has no such constraints; its model of text transcends output medium boundaries, and as such its models for approaching annotated content can be thought of a little differently as well. A linear but non-spatial stack of reader and internal annotation (footnotes and comments), which doubles as a bookmarking system for rapid navigation and is capable of collapsing all such comments down so that each instance takes up the same amount of space—to my mind these capabilities are all superior to the systems found elsewhere.
I think the aesthetic appeal of what is shown in your screenshots is undeniable. But aesthetics like that do come at a cost in most cases. Publications like that are going to most often by proofed page by page, just to ensure that all of the content boxes fit, that contextual information isn’t on the wrong page, that there are no collisions between boxes, etc. These are non-trivial problems to algorithmically solve—even sophisticated systems like LaTeX that can do the above, and might have, by the looks of it, in a non-real-time sense (minutes of compiling between edits!) will still require human operator proofing and oftentimes days if not weeks of tweaking the result—inserting a hyphen here, a vspace there, etc.
…point being: you probably aren’t going to get something as nice as that out of a real-time text editor.
Although I don’t think it is what you mean, we do indeed support the standard RTF comment on compile (and it should be a default in fact). You will get a result much like described above though,—little colourful boxes on a page in the margina area. I don’t know of anything that attempts to make notes look as nice as published output, for all of the above reasons and probably many more I am not thinking of.