yet i got this post as draft for so long time, sorry for delay
The problem for me was, knowing exactly what people have done when asking for help. Having things done in a ready made image was just easier, and let me know exactly the place where people started experiencing problems.
but now you are the only one maintainer for all the content and have an “obligation” of support, cannot really be tenable in the long run,
have external packages mean have different packagers
it also mean easy evolution without any new release, i just need package drastic or n64 emu to give them enable in my initial image
I could/should package the files into upgradeable packages, but like you said it’s not trivial
it’s more easy as you think, yet it need some rigor and could depend from the compilation process but it’s not hard
arch got the easiest package creation tool from far with makepkg tool, there exist 3rd party makedeb scripts who allow debian to do the same way
and I’d have to start again from scratch, using the 0.5 image as a base.
in my mind better way will be use bare vanilla debian armhf without any manually changed files,
we know how setup uboot, how create kernel with proper options & drivers, how compile & configure the gfx stack (mesa & x server)
what does we need else to have a full working system ? that’s what i done for porting arch
Maintaining a server to have current updated files for me is a fair bit of work, since it’s not something I usually do. I’d have to learn to do it essentially. If someone could assist in doing so, that would be great!
i got a running ppa server dedicated to the gs, that’s was one of my entry at the first compo along with a dedicated apt client (where full apt code still reside in fantasti without been used)
yet that wasn’t fun as a cat on roomba but the server is still alive and configured, off course it’s one of my personal server so if i down it down, a mirror more won’t be bad
The only thing I wouldn’t be able to change is the first boot screen.
uboot is the last part who’s not community builded, there are a repo with config for uboot, we need a try, the boot picture is show by uboot, but does we really need show a splashscreen and augment boot time for that ? fancy vs usability 
I’m not sure how much good me testing the kernels on different images would work, seeing as I don’t have any problems with any of them as it stands.
yet i was asked @jimfaker who got a problematic unit
my kernel differ from your one in some ways, the config is totally different, the patchs were split from months and maintained aside from your branch, kernel source is latest one 5.6.rc7 with an manually included lima 1.1 who must come with future 5.7 kernel
so knowing if it flicker too could be great and could give benefit to the twice kernels
I’ve only got R16 Gameshells
my initial one from first batch where a J revision, my screen ribbon was broken and i lost the keypad cross so i bought an used unit, who’s also a J revision but with 1GB ram this time
this flicker screen effect is pretty strange, we must debug it.
I guess once my R16-J board comes in the mail, we’ll find out then!
you may request @guu to make some test if he got time to find a faultly board, but i don’t think it’s a J revision issue, maybe a batch is more tolerant than other one yet but i think it’s a software issue
when you compiled the kernel, was you sure the patch forced the tclock divider to the correct value (6) ? kernel was changed the way to set the divider two time these months, patch must be fixed too