I've pinned down the origin of the bug: the information being provided by udev to usb_modeswitch is not what usb_modeswitch is expecting.  If my understanding of the udev documentation is correct, then there must be a bug in udev that is causing it to perform its %b substitution incorrectly.  Only an examination of the udev code can reveal why this is happening.

Recall that the line in /lib/udev/rules.d/40-usb_modeswitch.rules that gets matched for the K3520-Z is

ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="usb_modeswitch '%b/%k'"

The udev documentation states:

$id, %b
           The name of the device matched while searching the devpath upwards
           for SUBSYSTEMS, KERNELS, DRIVERS and ATTRS.

Thus for the above rule %b ought to be the name of the parent device for which idVendor is 19d2 and idProduct is 2000.

From an examination of the contents of /sys/bus/usb/devices I have been able to establish that the idVendor and idProduct files are in /sys/bus/usb/devices/7-1 so 7-1 is the device for which idVendor and idProduct matched.  If, however, you look back at the debug output from usb_modeswitch you will see the following:

Raw args from udev: 7-1:1.0/7-1:1.0

i.e. udev has told usb_modeswitch that 7-1:1.0 was the device for which idVendor and idProduct matched.  This misdirects usb_modeswitch into trying to read device data from /sys/bus/usb/devices/7-1:1.0 and as that directory does not contain  idVendor and idProduct files, usb_modeswitch is unable to identify the vendor and product with the result that it can't work out how to switch the dongle's mode.

By once again renaming the kernel module usb-storage.ko out of the way to prevent it automatically switching the K3770's mode, I have been able to do the same analysis for the interaction between udev and usb_modeswitch for that dongle.

The line in /lib/udev/rules.d/40-usb_modeswitch.rules that gets matched for the K3770 is

ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="14d1", RUN+="usb_modeswitch '%b/%k'"

so  %b ought to be the name of the parent device for which idVendor is 12d1 and idProduct is 14d1.   From an examination of the contents of /sys/bus/usb/devices it is evident that the idVendor and idProduct files are in /sys/bus/usb/devices/2-4 so 2-4 is the device for which idVendor and idProduct match.  In this instance the debug output from usb_modeswitch starts

Raw args from udev: /2-4:1.0

Bus ID for device not given by udev.
 Trying to determine it from kernel name (2-4:1.0) ...
Using top device dir /sys/bus/usb/devices/2-4

Once again udev has failed to pass the correct name of the device for which idVendor and idProduct matched, but this time it has passed a null value rather than an incorrect one.  Fortuitously usb_modeswitch seems to have code to cover this error, correctly deduces that the device directory to use is 2-4, and hence is able to read the idVendor and idProduct details successfully such that it can determine what steps are necessary to switch the dongle's mode.

And that's my last word on the subject (other than to answer my own question in the previous comment: I was indeed being naïve) for at least a month.  If no one has shown any interest in this bug by the time I get back from holiday, I might try taking a look at the udev code (if I can find it) to see if I can see what's going wrong there, always assuming that it's written in a programming language that I understand.