insert-kbd-macro can insert a number of different forms, but ultimately the definition of the macro can be either a string, a vector, or a lambda. If the macro definition is a string, then it outputs the form you are used to seeing. If it's a vector, then it outputs the form you now get. If the macro definition is a lambda, then the body of the macro will be printed as a call to
kmacro-lambda-form which builds the same lambda.
The last change to the
name-last-kbd-macro was commit 4f779ff8 in 2017, when it was removed and made an alias of
kmacro-name-last-macro has since 2004 always created a definition which is a lambda containing a vector, like this:
'([19 63 return 102 111 111 5 right]
(This is the lambda form that
insert-kbd-macro checks for).
Prior to this change
name-last-kbd-macro simply fset your choosen name with the value of
last-kbd-macro has been a vector of keys since at least 1995. However, in 1999 in commit f8a4db7d code was added to
start-kdb-macro that checked to see if the current value of
last-kbd-macro was a string. The comment says "Check the type of last-kbd-macro in case Lisp code changed it.", so perhaps there was some lisp code running around which replaced the value of
last-kbd-macro with a string instead of a vector. However, this particular code is only used when appending new keystrokes to the end of the most recently-recorded macro, and it converts the string back into a vector.
There's just one last place to look:
last-kbd-macro to the newly-defined macro using a function
make_event_array. This function creates either a string or a vector. It only creates a string if all the characters are less than 128 after masking off the CHAR_META bit "and all the bits above it. It's done this since the code was introduced in commit 7146af97 in 1991, so I suppose the comments about checking the type "in case Lisp code changed it" was somewhat mistaken. Here's the code from alloc.c, line 3672:
for (i = 0; i < nargs; i++)
/* The things that fit in a string
are characters that are in 0...127,
after discarding the meta bit and all the bits above it. */
if (!FIXNUMP (args[i])
|| (XFIXNUM (args[i]) & ~(-CHAR_META)) >= 0200)
return Fvector (nargs, args);
However, I notice that CHAR_META is the highest bit; all the other modifier bits have lower values than CHAR_META. CHAR_META has had the highest value since the constant was introduced in 1993, but prior to that it's really hard to tell. The check against CHAR_META in
make_event_array was also added in 1993 (in commit 736471d1); prior to that it accepted any character less than 256.
So, I conclude that you either had a really old version of Emacs, or that your memory is faulty, or that there's something else going on (such as modifications to the OSX port of Emacs that you used to use). Emacs has for at least the last 27 years output virtually all keyboard macros as vectors, unless they contained only ascii characters with no modifier keys, and only if the macro had not been named with
kmacro-name-last-macro (because then it would output the form evaluating to a lambda).
You could try patching
make_event_array to use CHAR_ALT instead of CHAR_META, so that it ignores all modifier keys, and see if that improves the situation at all. I'd try it myself, but my emacs build is slightly broken at the moment.