In this case they _are_ equivalent due to symmetry. If the other device _may_ assume that the connection is broken, then you _must_ assume that the connection is broken. Since either device _may_ assume that, both devices therefore _must_ according to spec.Only insofar as the kernel can not assume the device is still connected. If the kernel sees that it is immediately reconnected and has every reason to believe that the 'disconnect' was only a result of momentary power loss, and it can probably continue to access the device with no consequences, then it should do so.
No, as I said before, a good set of USB suspend scripts can solve this problem. All of the ones I am aware of *now* already sync all data, which is good enough to prevent data-loss in _every_ case where the device is spontaneously unplugged. On the other hand, this is _never_ good enough if the device is accidentally switched underneath us while suspended (and that's not so terribly uncommon, I know a lot of people who would do that accidentally, myself included).
I think most users prefer a system that works right when you use it right to one that doesn't break quite as badly when you do something stupid.
I think you just proved my point. Running the "sync" command a couple times then unplugging the USB stick basically never results in data loss even if the filesystem is mounted. Spontaneously switching block devices under a mounted filesystem is guaranteed to either panic the machine or cause massive data corruption or both.
Also why is this argument more valid for USB than SCSI? I am just as free to unplug a scsi disk and replace it with a different one while hibernated, yet I don't suffer data loss when I don't do such foolishness.
SCSI != USB. Users generally don't expect to hotplug SCSI devices while booted and running (with the exception of some _really_ expensive hotplug-bays where we expect the admin to know what the hell they're doing). On the other hand, users _do_ expect to hotplug random USB devices whenever they feel like it.