Chatted to possy, and by the time we got to look at it, it had mysteriously stopped happening. Checked the pnpqueue table based on your suggestion and predictably it was empty.
As I say, this isn't the first time the exact same thing has happened to me and the previous time it was a completely different build. Looks like the StorageDevices_SambaRadar script got stuck in a hole, with a bunch of error text messages it was parsing trying to scan as networks, and thus failing. Would love to know whether these were actually queued in the pnpqueue table. But I suspect not - I think it was still looping through the script and processing script errors as if they were networks. I don't have any reason to believe that something else had queued junk data into the pnpqueue as they seemed to be errors internal to that script. For my further understanding:
1) what is responsible for populating the pnp queue?
2) what is responsible for reading the pnpqueue and then calling StorageDevices_SambaRadar with that info?
3) StorageDevices_SambaRadar seems to be self contained in terms of scanning the network based on a subnet passed to it, so is it really related to the pnpqueue at all?
Coming back to that script - the stuff above are just symptoms. The cause seems to be that when the script is called and passed a subnet, in the form 192.168.80.1/24, when the issue happened it was passed 192.168.80.1/ which caused an unhandled error, and the error messages that resulted are then parsed as if they are devices on the network and the core tries to add them. Working backwards through the scripts network_parameters seems to be the one that passes the dodgy network, maybe from a semi-failed SQL query? (particularly, the IntNetmask seems not to be set correctly)
In any case, I guess there is room for improvement in both the radar's error handling and tracking down a possible bug in the previous script... but I'm no where near confident enough to attack that!