I guess it should not be too much of a difference except for maybe disk space usage.
I also tried the alternative with --vmsize 3500M. It works the same, expanding the disk size to fill the whole device is maybe a little bit easier with this approach.
I can take a look, but I’m not sure how well it would integrate with my build infrastructure. I guess in particular the upload will be very slow.
No, I don’t have any older images. You could try to build a (stretch) version with some 14.* git tag around the beginning of the year. I don’t know if it will buil though and it would be outdated obviously.
Doubtful. I already asked someone for help, nothing came out of this. At the least I’d need some new hardware for my security wellbeing /dedicated buildmachine and for testing (like rpi 3+) and maybe (maybe) some other “infrastructural” changes. Until then I’m limited mostly to theoretical “work”
We don’t have any packages supporting cross compilation.  These “special” packages are amd64 only (Intel and AMD) at the source code level. For example LKRG is linux, amd64 only. It’s non-trivial to port them to other architectures.
A guide on “how to cross compile” won’t cut it. A guide “how to cross compile” would work if these were simple packages similar to the hello package which does not have any architecture specific source code.
 At least none where that’s worth it. For packages that support cross compilation, that is already supported. kloak can be cross compiled on amd64 for “i386” (more “i686”). Not interesting/worth it though due to this. What would be interesting / worth it though would be to cross compile to arm64 which however has issues which probably only upstream can solve.