Question about native compilation (bug?)

[Drew Adams]

I don't have native compilation for my laptop, but I received a bug report from 
a user of one of my libraries, and I get the feeling that native compilation 
(which this user has) is interfering and perhaps bugged.

1. My code, when loaded, saves the original definitions of some functions, such 
as `read-buffer', by creating a `defalias' for each of them, such as this one:

(defalias 'ORIG-read-buffer
          (symbol-function 'read-buffer)

2. I define a global minor mode that, when turned on, redefines those saved 
functions, such as `read-buffer', using `fset', to using definitions 
appropriate to the minor mode.  

3. When the minor mode is turned off I reset those function definitions to the 
saved (`defalias'ed) versions, using `fset'.

(I do this dance because I want the library to work properly also with older 
Emacs versions.  No comments, please, about its fragility or other weaknesses.)
___

This is the problem, reported in Emacs 28.2 with native compilation:

Emacs 28 added an additional optional arg to function `read-buffer' (which is 
defined in C).  My substitute version of `read-buffer', which is used when my 
minor mode is turned on, has only 1 required arg and 2 optional, not 1 required 
and 3 optional.

Obviously, for any code that will try to pass 4 args, I need to update my code 
to accommodate the 4th arg.  I haven't done that yet.

But my question is about code that ostensibly passes 3 or fewer args.  An error 
is nevertheless raised, saying that 4 args were passed and only 3 were allowed. 
 The standard code, whose vanilla source definition (in `window.el') passes 
only 3 args, in actuality, at runtime, passes 4 args, the 4th one being 
explicitly nil.

Recipe: the minor mode is turned on, and `C-x 5 b' is tried.  An error is 
raised:

Debugger entered--Lisp error: (wrong-number-of-arguments #<subr my-read-buffer> 
4)
  read-buffer("Switch to buffer in other frame: " #<buffer foo> 
confirm-after-completion nil)
  read-buffer-to-switch("Switch to buffer in other frame: ")
  byte-code("\300\301!C\207" [read-buffer-to-switch "Switch to buffer in other 
frame: "] 2)
  call-interactively(switch-to-buffer-other-frame nil nil)
  command-execute(switch-to-buffer-other-frame)

I wouldn't have a clue to what is going on here from that backtrace, since 
function `my-read-buffer' accepts 3 args and the source code for 
`read-buffer-to-switch' passes 3 args.

I got a glue (I think), from this: For the reporting user `C-h k C-x 5 b' says 
this:

C-x 5 b runs the command switch-to-buffer-other-frame (found in global-map), 
which is an interactive native-compiled Lisp function in 
'/var/lib/snapd/snap/emacs/2031/usr/share/emacs/28.2/lisp/window.el'.

It's that "native-compiled" that makes me wonder.  If the user loads the Lisp 
source file, `window.el', there's no problem.  But it looks kinda like native 
compilation has "baked-in" the call to `read-buffer', passing an explicit 4th 
arg, nil, instead of passing only the 3 args that the source code says to pass.

Passing 4 args, the last of which is nil, isn't the same thing as passing 3 
args, but it looks like native compilation takes a shortcut, assuming that it's 
the same thing.

Is this a native-compilation bug?  Is it some other Emacs bug?  Or is this just 
the way things are going to be from now on - "situation normale, rien à 
signaler"?

Let me know, if my guesses are near the target, or if I'm missing something.