Didn't try anything more. Didn't code more than 5 mins in days. 
Also, on the minipc it takes some hours to compile the openmsx source, so not going to do it daily.
Well, there aren't daily changes. Especially not now, just before a release 
So just a recent version is already very useful to try out.
Also, ever thought about cross-compiling?
It works nicely for me
The only problem I've seen with the very last version in github, is that before I could attach two openMSX processes to two different debuggers (it's useful to figure out why a programs works in one machine and not in others), but now the second debugger does not attach if there's another one already running. It simply does nothing when clicking on "connect".
I don't know if it's because of a change in openMSX or the debugger, or something else, though.
Also, ever thought about cross-compiling?
Yes but I don't wanna mix things on main computer, specially config files that proved to be not totally compatible on the newer version, and don't wanna them duplicated, plus duplicated machines... I have some special one without boot logo just to use as a PT3 player. I know there's a PT3 player and it works on linux too, I use it, but I wanted to add more formats and stuffs... Sometimes it's only because "why not".
Also, ever thought about AppImage? 
Not sure if this is related to the emulator or the debugger, but for a long while, and still present in the later 17-builds, is that the debugger often is unable to connect to openmsx if you have a tcl-script running. I often have a profiler-script or the vars.tcl-script running. In many cases, when attempting to connect the debugger, I get an eternal windows-rotating-circle. Sorry, but I haven't reported this earlier. The reason is that, as I have found a workaround, I haven't really dug too deep into it - as often is what you should do when reporting, so that devs can fix things quickly.
This might be known? The current workaround is to just not load the scripts
