We already have a util.execute() in base/ffi/util.lua - so even if this one's argument may be different, this could become confusing.
Also see FileManager:moveFile() in frontend/apps/filemanager/filemanager.lua.
We also have a util.shell_escape(args) used in readerdictionary.lua, which might be better at handling the quoting you do below (or not, dunno :).
Anyway, using the shell like you do here (and like we do elsewhere, because nobody cleaned that up :) is a bit odd and ugly, when Lua has a os.rename().

You know more than us about what kind of stuff can be in your scripts.always/afterupdate, and if they are fine being executed that late.
But I feel the Android patch.lua might be used to tweak the framebuffer dimensions (@pazos ? @NiLuJe ) , and I guess it needs to be run before reader.lua - or may be at its very top. So, you might need to stage in live.patch.lua, that you could import early and run the 0* scripts early, and others later ?
Or local livepatch = require("livepatch") at top and have it run any existing patch.lua (without moving it) at require time - and for the later stuff, here do livepatch.executeLivePatches()

I'm not sure this split of setupkoenvs into setupkopaths is really needed - as setupkoenv doesn't seem to use anything from the DataStorage stuff (and the loading of defaults.persistent.lua that happens just after what I could select to comment on :) and the require("setupkoenv") that happens just after.
So, I guess you could just move the require("setupkoenv") where you put your require("setupkopaths").
I also guess no patch/livepatch stuff would need to tweak the ffi load stuff hat happens in setupkoenv, and this patching stuff might actually be happy to have the ffi loading stuff available.

Hmm, the current implementation is as close to the deleted Android one as possible. Splitting setupkoenv in two parts allows:
1.) to patch the search paths (e.g. a custom plugin) and
2.) copy some .so libraries before they are used (e.g. crengine).
(So a really developer, testing thing).

The 2nd part of setupkoenv.lua does not load any library (I think, @NiLuJe ?), it just redefines ffi.load, so I think this won't hurt if done early if you just move the require("setupkoenv") where you put your require("setupkopaths").

OK, let's wait on @NiLuJe.

"master-patch.lua" feels a bit unprecise (why "master" ?). "early-patch.lua" would sound more true.
And if we allow multiple "late" patch files, why only a single "early" file ?
Also, dunno about moving an existing patch.lua (I would just run it early if it exists).

I wanted to bundle all developer scripts and patches in as least places as possible. IMHO an additional patch.lua feels weird.

And I did not want to change existing behaviour, so we already have scripts.always and scripts.afterupdate. But you could complain that patches does not fit in that row. So what about renaming patches-> scripts.late (And I move the early-patch.lua into scripts.always).

Note to self: Check if folder exists, before moving.

IMHO an additional patch.lua feels weird.

I mean, don't advertise about it, but if there is one (legacy user), run it if found.
But advertise the new common way to do that.

I wanted to bundle all developer scripts and patches in as least places as possible

So do I :)

And I did not want to change existing behaviour

I have no problem with changeing it, current users are rare (mostly us), and will notice it and update it according to the new way/documention :) I don't think we would need to do any migration about them.
(Except for patch.lua that some old users may have added one with viewport stuff specific to their devices, and that could have forgotten about it - so either keep it in its original place and use it if found - or move it as you did.)

If we don't change anything, these directory names will sound inconsistent:

scripts.always/       (ok, always, but late or early ?)
scripts.afterupdate/  (ok, only after update, but always or early ? :)
scripts.late/         (ok, late, but always I guess)

So, we might want to decide about a generic futureproof scheme. Directories (but they would clutter koreader/ directory), convention about filenames (like /etc/rc1.d/ ... rc6.d/ on old Unix) in a single directory (patch/ livepatch/ userscripts/?) ?

Yep inconsistent. May I propose:

livepatches/early_afterupdate  (early and after an update)
livepatches/early              (early independend to updates)
livepatches/late               (late independend to updates)

These would be subdirectories ? or filenames ? or filename prefixes ?

Also, livepatches and livepatch.lua may better be named userpatch.lua, to make it obvious it's for handling... users' patches :) (or is the notion of "live" patch to distinguish from manual code patching is important ?)

Thees would be subdirectories, with files and folders in them.

userpatches/early_afterupdate/  (early and after an update)
userpatches/early/              (early independend to updates)
userpatches/late/               (late independend to updates)

with files and folders in them.

Felt like overengineering :) but I guess "folders in them" is just for content that should be copied into koreader's own tree, like hyphenation files ? (and you would not want a tweaked translator.lua - to be copied over koreader's one - to lie into userpatches/early/ and be considered a patch itself).

I guess personally, I would have gone with:
file starting with 0-* : early patch
file starting with 1-* : later patch
file starting with 0somethingelse-* afterupdate early patch (no real idea for a prefix :)
anything else: ignore.
So everything is quite visible in that layout, and you can just rename a file (add a NOT_0-test.lua prefix) to have it not considered.

What for do you use this "/migrate/" stuff ? For your german hyphenation test file ? Anything else ?
Dunno if other users than you do use this feature - but may be we could simplify the amount of available tricks :) and just use early and last lua scripts. You could do any move/migration from a Lua script (even if shell scripts might be easier to write for that kind of thing), it would feel cleaner to me.
You could add helpers methods in this livepatch.lua so shell stuff like cp can be easily done in a lua file.

(I'm having a hard time understanding what's possible and what happens when reading this new linvepatch.lua.)

And if "migrate" stuff only do copy of files from the user dir into koreader distributed dir, I would at least don't use the word "migrate" in the code/comments, and it feels to me you are migrating some files/settings. Just "copy" would work and read clearer.

Originally I thought that it was you, who wanted and implemented the migrate thing ;) But after studying the old commits I believe @pazos introduced the migrate functionality.
I don't use migrate at all. So, if we want to drop it, I would be glad ;)

One question concerning the execute function. Now it uses os.execute. Would it be of any benefit to use os.rename and os.remove where possible?

Pure Lua for clarity, and it would avoid some issues with executing /bin/mv via the shell and the need to escape filenames properly.

Good idea, looks logical :)

is that early%-patch%.lua check still needed ? or leftover ?

a harmless leftover -> to be removed.

return nil?

No!. Returning the whole field, will allow us to call the no-op applyPatches even on F-Droid -> see below.

I don't want this logged unconditionally each time the program starts on devices/users that don't use this feature.

Yepp, that's just for testing this PR -> will be removed.

what is the purpose of running arbitrary shell scripts?

Now that you have hooks available to run arbitrary lua code sounds easier to just call shell/python or perl scripts from your own lua patches.

Executing shell scripts is a 4-liner and why not use it. If you want execute patch .... it would be clumsy to write a patch.lua and execute the patch command there.

One last update of this date :) and we're good to go.

That was a long birth. But it looks good ;)