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

[Dmitry Gutov <dgutov@yandex.ru>]

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.