FWIW, I also got a similar error "the content could not be opened" or so right after updating my Kindle Touch to version 3.1.0. Rebooting the device seems to have fixed that, too, and it never reappeared.
As hard as I try, I can't come up with an explanation, let alone a solution. JBPatch patches do exactly one thing: modify java bytecode after it was read from a file, but before it is actually interpreted as bytecode by the JVM. These modifications are deterministic - either they don't happen at all, or they happen in the exact same way, every time. In other words: if a patch was the culprit, then it would either fuck up every time, or never.
The only thing that I can think of which might influence the whole procedure (attention: wild speculations ahead!) is the /var/local/java/default folder, which seems to contain cached(?) copies of some java classes. I never figured out what that folder is good for. And the Java VM that the Kindles use seems to be closed source, i.e., cvm isn't documented (AFAIK; but I dimly recall that either twobob or knc1 had at least a bit more insight into where it comes from).
Continuing with the wild speculation: it might be that the VM tries to use a cached class together with a "newly patched" one. And it might be that a restart (or actually, a crash which is noticed by whatever caches things, and then tells the cache to empty itself for the next reboot) fixes these issues.
I don't know... I honestly don't know what the Kindles are doing. All that I know is that the JBPatch framework, and the individual patches which are released, are 100% compliant with the JVM specification, and correctly do what they're supposed to do. Why the framework around them is crashing is beyond me.
Sad but true: the "Windows approach" seems to help - "If it doesn't work, reboot. If it still doesn't work, reboot again."
