hello. I think a clue lies in a snippet of the wsmux(4) man page: If a wskbd(4), wsbell(4), or wsmouse(4) device is opened despite having a mux it will be detached from the mux.
If I had to wager a guess as to what's going on, I'd say that when you start the system, the wsmouse0 gets attached to wsmux2 when the system comes up, but by the time you unplug the mouse and plug it in again, your application has the /dev/wsmouse0 device open, which causes the newly attached mouse to not get attached to the mux. Even though your application is a replacement for init, it still runs too late to intercept the attaching of the mouse to the mux, which is happening before any processes are spawned. I wonder if you can fix this by using drvctl to detach the mouse, then usbdevctl to reprobe the USB bus and reattach it and thus activate it for your application. Alternatively, I think I misread your original message and you're opening wsmux2, not wsmouse0 with your application. If that's true, then this snippet from the manual suggests that if you open wsmouse0, rather than wsmux2, you can force the mouse input to come to your application directly, rather than going to the mux. If my second scenario is correct, then I'd say there's a bug in the system since I think in that case, the mouse is getting attached to wsmux0 despite your kernel config entry, at least, on boot up. In any case, I'm sure I only half know what I'm talking about and, even that half, might be suspect. With that said, perhaps this will give you a clue on something to try next. -thanks -Brian