To add another perspective here: because this is seeded in ubuntu-server we wind up running multipathd on our Pi server images. These run on big fat 8GB Pi 4s (where presumably no-one really notices), but also 512MB Pi Zero 2s where the 25MB of RAM that multipathd consumes represents 5% of all the RAM on the system (and typically about 10% of the available RAM at runtime). Given there's little prospect of attaching multipath hardware to such a machine this seems somewhat wasteful :)
Socket activation would certainly help in this use-case (though I'm not sure it's actually that useful for the PC use-case as it would imply multipathd wouldn't run until the CLI was used?), but for the time being I've recommended Pi server users add multipath=off to their kernel config on the smaller Pis to save a bit of memory.
To add another perspective here: because this is seeded in ubuntu-server we wind up running multipathd on our Pi server images. These run on big fat 8GB Pi 4s (where presumably no-one really notices), but also 512MB Pi Zero 2s where the 25MB of RAM that multipathd consumes represents 5% of all the RAM on the system (and typically about 10% of the available RAM at runtime). Given there's little prospect of attaching multipath hardware to such a machine this seems somewhat wasteful :)
Socket activation would certainly help in this use-case (though I'm not sure it's actually that useful for the PC use-case as it would imply multipathd wouldn't run until the CLI was used?), but for the time being I've recommended Pi server users add multipath=off to their kernel config on the smaller Pis to save a bit of memory.