bug#59067: 29.0.50; Exexpected overlay order in `overlays-in' return value

[Dmitry Gutov]

On 10.11.2022 22:51, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> > > Maybe Someone™ should browse through the various calls to `overlays-in`
> > > out there to try and see which orderings could be useful.
> > FWIW, mmm-mode uses overlay sorting based on the value of overlay-start
> > (first come overlays where this value is higher, so basically the more
> > deeply nested ones, if we imagine all overlays to be strictly nested, as is
> > the case with mmm-mode).
> AFAICT it sorts first based on priority and only for equal-priority
> overlays does it use the overlay's start.
>
> Is there any specific reason for this particular ordering?

Historical, I suppose. mmm-mode doesn't set the 'priority' property 
these days (the little snippet of code doing that is commented out).

It kind of makes sense, but I don't have a better argument than that.

> > You can check it out here, it also seems reasonable as the potential default
> > sort:
> > https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/mmm-region.el?h=externals/mmm-mode#n148
> >
> > If it's not too expensive to use as default, that is.
> I was thinking of doing like we did for `overlays-at`, i.e. leave the
> default to "unsorted" but add a `sorted` argument.  This also acts as
> a reminder that the default is not sorted.

Yeah, ok.