idk if useful, but fwiw, for me at least, i think of org's mark ring as primarily and usually a reliable back button, like a browser's. mainly for links and link-like navigating actions. especially for use cases like this: refile goto to a target heading in any file, whether same or not, then pop back to where you were using org-mark-ring-goto. it's quick, pretty much certain to go to the spot you were when you followed the link, and rather convenient. i use it for when i have a link to something and want to use it as reference for what i am doing locally.

nothing new but i think of the local mark ring as holding interesting point locs that you can go back to. commands like m-< that move point save mark there automatically.

hence my suggestion to use the local mark ring for the case where you refile goto a heading so as not to lose where you were in the target buffer, after going to target buffer but before going to target heading. this is analogous to m-< pushing mark so that you do not lose your place.

so in this formula, with using local mark, refile goto works like this: after doing refile goto, org-mark-ring-goto takes you back to where you were before you did refile goto, just as it does now. no modification of code is necessary for this. and c-u c-spc takes you to the loation in the buffer where point was before refile goto went to the target heading [after it went to the buffer]. what is necesary for this is pushing mark after visiting the target buffer but before visiting the target heading.

so that would be an alternate implementation. either one will get me what i want, which is to not lose the location, but the above preserves the link-oriented back button idea also. ei

other commands set local mark as part of their operation or so that you can go back because they might be interesting or distant. also you can set mark to a location you might want to go back to.

then there is the emacs global ring, which makes sense in principle because emacs is multi-buffer, but which i have never gotten to be useful. in reality i think all 3 could perhaps use redesigning.

a redesign: i think it would probably be great if all three rings stopped being rings and started being trees, much like undo-tree, perhaps even with visualizer, with a consistent interface. if you think of info's navigation commands like l and r, you can imagine various things you can do. in undo-tree and vundo you can switch branches for the next place you might want to go to. point locs could use the same type of navigation commands.

in principle org's mark ring could even be generalized to more kinds of links, such as paths or tses, and org could grow a global minor mode for links [expanded idea of].

the spec applies to local, global, and link oriented, with an expanded idea of links to include such things, if desired by user, as identifiers, timestamps, bare fs paths, and many other things.

dispatcher f and b go to next and prev point loc in buffer, much like m-tab in org. it is settable on the fly whether it navigates local, global, or link, or it can use different prefixes or initial key sequences.

Dispatcher l and r go back and forward
in history of point, regardless of
buffer. Thus, dispatcher RET then
dispatcher l returns to point, even if
point was not on a link. The bindings
are modeled on l and r in info or help.

Dispatcher n and p change at branching
points, cycling you to the different
places r might go and back.

Dispatcher l and r are repeatable as l
and r; dispatcher n and p are repeatable
as n and p.

These commands apply to marks anywhere
in Emacs, not only ones related to
links. Thus they are more general than
link commands. You can use them for
finding interesting places in your use
of Emacs, such as where you set mark.

this isn't the complete idea but just gives a flavor. the idea is that point locations, whether local, global, or link-oriented, are worth having a consistent or at least analogous ui.