or trampolining to a byte-code vector in the constants array, but then realized you would have to
either make sure there could be no "gotos" between the segments or do a real trampoline to
an explicit label. And in either case you would have to save the contents of the stack frame
and reinstate them in the continuation byte-code call, and I don't see any byte-codes that would
support that. Otherwise you could only do it when you know there is no stack in use, which is what I believe
your solution effectively does.
On the other hand, given the code for patching up byte-code in byte-compile-lapcode, you could
explicitly byte-compile a thunk for every top-level _expression_, then glue them together until they would exceed
the 65K pc limit, then do another segment, etc, and do a simple trampoline between the resulting byte-code vectors,
or no trampoline if there were only one required. Strictly speaking, gluing them all together is really an optimization
of creating byte-code vectors (thunks) for each top-level _expression_, and looping over the collection of them, invoking
each one in turn.
As long as I'm looking at the compile log, I also see a lot of errors of the form:
package-quickstart2.el:14739:39: Warning: The compiler ignores ‘autoload’ except at top level. You should
probably put the autoload of the macro ‘bind-map-for-minor-mode’ at top-level.
This message is only reported for macros - there are plenty of autoload expressions that do not generate this
message despite being in the same kind of "let" form.
Lynn