I am painfully aware that I'm hitting the envelope of my knowledge, pretty hard.
"The annoying thing about driver modules is that module initialisation, which includes binding to and probing all the devices they can handle, is serialised."
It strikes me, however, that the basic problem *here* is finding out what hardware is present and not present. In the vast majority of cases, I'd wager that this really only needs done once (rather like the crypto hardware tests): upon installation. Beyond that, what's needed is graceful fallback for the rarer cases the hardware isn't present anymore, and what we already have: new hardware detection.
This could be mitigated by means of a table of "known to be present" hardware information supplied to a bulk-loaded module set (something along the lines of putting all the .ko's into a single .ko with tables specifying that it's a bulk module and where everybody's at in it, as outlined above.) If intialization of the known hardware fails, then it could perhaps fall back to probing.