Yeah #2 just seems like a logic error… and your focus was actually the container MUS container here, not it’s base image 
.
Re Mosquitto and openrc …
On #1 with mosquitto… mosquitto is really solid under /container when started via its foreground mode (which can be backgrounded by shell) outside of openrc.
I do know at least one issue may be the /run directory openrc uses to store PID files. It’s writable by /container by root, but if openrc/service does some chown/chmod things & uses some service/daemon user (i.e. mosquitto) so it the non-root user can “see” /run/mosquitto files with the PID of service openrc started… But these can permissions can get “lost” on the /run directory after restart (or perhaps elsewhere)… so when openrc+mosquitto cannot write the PID, this causes errors – since it assumes the chmod/chown were done when added as service and PID file exist (or readable). So, AFAIK, it the /run PID that fails - do not know exact where/when – but openrc thinks it’s not running because the PID file in /run was not created (or has no-permissions/etc). Same happens else with openrc things, like postgres.
To be honest, I’ve kinda given up on openrc - now tried a few times since /container come out - but the whole idea of using a packages is they “just work”. And since Alpine does have a lot of openrc-ready packages, it be handy. I did look at some point look at some “s6 overlay” projects too, see https://github.com/just-containers/s6-overlay among others, that do similar shoehorning as you. But s6 is even more complex… just make some init scripts work.
So for services like mosquitto which have a “foreground mode” - that can just be backgrounded via shell… a bash script with essentially some “mqtt &; lighttpd” may not be as bad. I’ve been trying a novel scheme using Makefiles with make parallel builds (-j <max_processes_to_use>) to mimic Docker’s “bash job control” method - essentially make replaces bash in the scheme, with multiple foreground service/daemons being just parallel build steps that never finish (with the make -j option). make also deals with deps, organizing shell code in targets, and logs all the process info with “-d” so it logs automatically if process dies, or when starting new processes as part of a dependency chains. More conceptional, but I published my “make.d” container experiment just to show the approach: https://github.com/tikoci/make.d - which has worked for IoT project I’ve been working (that needs mqtt & http for a simple internal web page), but also worked for fun here: http://forum.mikrotik.com/t/piano-interactive-player-piano-studio-quality-recorder-using-beep/173756/1 which run both “mqtt” and “midimonster” in a RouterOS “make.d” container to connect MIDI to MQTT (and being make, it compiles midimonster as part of service start if needed). Not for production use, but for test/experimenenting it works. It just plain Alpine with make and some Makefile installed to help bring up Alpine things using make - the CMD/cmd= and ENTRYPOINT/entrypoint= are changeable and up to user whether make is the “init” or a process (+package) installed by make in the end.