> This patch passed all my, admittedly limited, test cases.

Thanks for checking.

 > In the patch, `make-frame-names-alist` returns only frames on the same
 > display. I don't know if this is a behaviour change or to make it
 > consistent with `next-frame` (the doc of `next-frame` doesn't mention
 > displays -- might worth clarifying there if this is the behaviour).

Thanks for spotting this.  'make-frame-names-alist' didn't have a
doc-string.  It only contained the comment

   ;; Only consider the frames on the same display.

so I thought that was the intended behavior.  In fact it wasn't so I
changed that now.

 > Another minor/unimportant point (feel free to ignore) is that the
 > patch also allows `make-frame-names-alist` to accept a FRAME
 > argument. I think it would be more natural to return frames on the
 > same display as the passed FRAME rather than the selected one.

I added the "(&optional frame)" because with a few exceptions most
frame-related functions have it so coders don't have to think twice when
calling any of these functions.

I attach a new version which also implements 'frame-list-1' in a
different way.  It's illustrative to look into how 'frame-list' and
'frame-list-1' relate.  With the following

(defun make-frames (number)
   (let ((i 0))
     (set-frame-parameter nil 'name (number-to-string (setq i (1+ i))))
     (while (< i number)
       (set-frame-parameter
        (make-frame) 'name (number-to-string (setq i (1+ i)))))))

make four frames via

(make-frames 4)

with titles "1" to "4".  Now when evaluating

(frame-list)
(frame-list-1)

the result for the latter will change when you switch to another frame
while the former remains unaltered.  I have no idea if it's that what we
want for 'make-frame-names-alist' but 'frame-list-1' should preserve the
old behavior.

Note here that we always list frames in the reverse order of their
creation.  This means that with respect to the selected frame,
'next-frame' conceptually returns the frame created previously and
'previous-frame' the one created next (unless these functions wrap
around, obviously) since both of these are based on the underlying
Vframe_list which is reproduced by 'frame-list'.

martin