I had some problems with musl last year and had to back out using it for an embedded system. Typically for example, 2 threads listening to their own socket bound using REUSEPORT wouldn't work; half the connection would arrive on a thread and the second one wouldn't get anything. That scared me a bit as I was on a deadline to deliver, so I had to quickly recompile my distro with glibc, and the problem disappeared.
I really wish it worked as I like the lean&mean&precise approach they've been using!
Other than #define'ing SO_REUSEPORT, libc has no role whatsoever in its behavior. You can see this yourself by grep'ing for SO_REUSEPORT in the glibc and musl source code. And both glibc and musl implement 1:1 threading, so it's the kernel making all the thread scheduling and inbound connection queueing decisions.
Your problem lay elsewhere, unless you were using a really old version of musl that lacked the SO_REUSEPORT definition.
I do not have an explanation either. I'm more of a kernel guy so I realized it "should" have worked but it didn't. I suspect perhaps a thread wakening issue of some sort, as the connections were definitely 'queued' on the listen socket. I know that that same code worked perfectly with glibc!
I really wish it worked as I like the lean&mean&precise approach they've been using!