Consider what suspend to disc/hibernation is. You store all the registers, data in buffers, RAM contents, filesystem state, hardware set-ups, absolutely every thing in a special file and then cut the power. On resume, the system loads all this back into its appropriate places and tries to carry on from where it left off. It quickly discovers the hardware clock has changed and corrects its time, but if anything else has changed it won't know about it until an error occurs when it tries to use the device or access the file, write out buffers or whatever, and the disc state is not what it should be, causing errors the system can't explain except by assuming a major hardware fault or data corruption has occurred. At that point, any kernel must conclude it is unsafe to continue processing data in the inexplicably changed environment and can only dump debugging information and exit to protect data from further damage and aid a proper investigation.
It is possible you might escape this if the two systems have no shared partitions, but I'm not even sure about that. From a kernel's viewpoint, something has changed over which it had no control and that indicates something is seriously wrong, since the kernel is supposed to be in total control of the system. Any decent kernel should not tolerate such changes. As I recall, Windows will blue screen and Linux will ooops if you do this, and so they should.
