That's probably a sensible guess.
FWIW, what I did the last time (after first noticing the issue outside of Nickel entirely), is simply to enable the force wifi flag, and then to look at what's happening before/during/after the USBMS session in an SSH shell (... one that doesn't have its claws on onboard itself, though ^^), mostly by poking at dmesg, the syslog, the procfs tree and lsof.
(Nickel does a lazy unmount, which means you'll see a whole lot of fds pointing to / instead of /mnt/onboard, since that's how the magic happens
).
Another thing that changed on 4.31: all the kernels have been updated, and I don't have the source delta to tell you how exactly, except for a relevant bit on mx6sll & mx6ull devices, where most of the USBMS machinery is now built-in to the kernel, instead of being pluggable modules (this *will* affect timings, which is a sensible issue on NTX boards ^^).
Patches shouldn't have any impact on fs handles; nor should NM (barring direct user interaction with NM and very unlucky timing, and even then, highly unlikely).
KOReader/Plato won't have any impact on this, since they're completely inert inside Nickel. Restarting Nickel after a KOReader/Plato session *might* exacerbate/uncover weird issues though, but nothing on a cold boot.
NanoClock is a very sneaky piece of trickery, so I can't honestly say no, although I wouldn't think it would affect these sorts of things (i.e., on some devices, it's more likely to crash the kernel during the import progress bar than anything else ;p).
NickelSeries interacts directly with the import process, so, who knows, but, much like NickelMenu, it's by definition bound by Nickel's own constraints.