Why does Emacs make it difficult for me to have two frames open the same buffer

No, the *Bookmark List * buffer is not directly editable. But there are commands (keys) for editing bookmarks that are displayed there. You mentioned r. There are also e and E, depending what part of a bookmark you want to change. Not to mention several keys for editing a bookmark's tags.

As for recuperating existing text to reuse (edit) it, that should be trivial. The current value is available as a default value (M-n, M-p). Or you can copy it from a help buffer: C-h RET gives help on the current-line's bookmark (in buffer *Help*), and with a prefix arg the full bookmark record is shown, i.e., the Lisp sexp representing the bookmark, which is in your bookmark file (~/.emacs.bmk, by default).

The current values of any part of a bookmark that you would want to edit are thus easily available - you should never have to start from scratch.

If you want to open the whole file (which requires ), but show only part of it in the editor window, use narrowing. Select the part of the buffer you want to work on and press C-x n n (narrow-to-region). Say “yes” if you get a prompt about a disabled command. Press C-x n w (widen) to see the whole buffer again. If you save the buffer, the complete file is selected: all the data is still there, narrowing only restricts what you see.

If you want to view a part of a file, you can insert it into the current buffer with shell-command with a prefix argument (M-1 M-!); run the appropriate command to extract the desired lines, e.g. <huge.txt tail -n +57890001 | head -n 11.

There is also a Lisp function insert-file-contents which can take a byte range. You can invoke it with M-: (eval-expression):

(insert-file-contents "huge.txt" nil 456789000 456791000)

Note that you may run into the integer size limit (version- and platform-dependent, check the value of most-positive-fixnum).

In theory it would be possible to write an Emacs mode that loads and saves parts of files transparently as needed (though the limit on integer sizes would make using actual file offsets impossible on 32-bit machines). The only effort in that direction that I know of is VLF (GitHub link here).