It is more the former than anything else, along with some practical things to consider that would fall under the latter. There are conceptual design issues with storing this in a permanent fashion, within a largely volatile environment.
You can see the side-effects of that even in the part that does work, in the history queue. As a test throw five single-paragraph items into a Multiple Selection scrivenings session. Put the cursor into the 3rd, selecting a few words, and use the Highlight function to mark it for future reference—leave the selection untouched, and click on the second item alone in the binder. Paste in a few thousand words of junk text. Lastly, press the Back button in the browser to return to your scrivenings session.
Oops! The selection is technically right where you left it, n number of characters from the start, and y number of characters long. Only now it’s in the beginning of the second item, which now extends down quite a ways before we get to the highlighted text we marked in the third item.
So that’s something that can happen even in history, but we figured that the chances of that happening in a way that is confusing or frustrating will be greatly minimised by the fact that most people don’t use history beyond the present tense. The chances of you making dramatic edits to components within the session are much lower. This “error” can be encountered for other reasons too, such as shuffling the order of things in the binder, deleting sections, etc.
You can perhaps see now where these problems would become much more obvious, much more confusing, and much more frustrating, when you’re storing the cursor position forever on elements that will almost certainly gradually become dramatically different than the last time you viewed them in scrivenings (maybe years ago), given the nature of the software being a writing program and all.
I think it is fair to say that over time, this would eventually start to feel random, and that there is a sensible temporal limit on how long that data would be useful—one where we already kind of a have a kind of temporal limited and has an implementation created: history.
In summary: I do not see any practical problem with our current suggestion for workflow. If we accept that stored offsets will degrade over time, and accept that they will only remain useful in recently worked within sessions, then the suggestion to use History to return to these sessions, instead of repeatedly navigating to them fresh (bloating the history and making it less useful), is not an imposition or workaround: it’s just good use of the software’s existing capabilities and tapping into its strengths, to get the result you’re looking for.