Documentation and a Visualforce State Test I too have not found any documentation on this, which is odd because I do recall knowledge of VF page states getting invalidated when an upgrade occurs. As in when you change the controller in DE org and try to continue to use the page without a full refresh. Again though I can find no reference to this either sadly. That said it ought to be easy to test, here is what I did....
- Write a Helloworld Page that accepts input from the user and echos it back to the page. This results in the page having some kind of state.
- Packaged it (managed) and installed it in another org, ran up the page and used it.
- While leaving the page open, i uploaded a new version of the package with a different Apex controller (renamed a variable in the controller) and upgraded the package in my test subscriber org.
- Went back to the tab in my browser still open from the first step and clicked my Say Hello button, i recevied the following message.
An administrator has changed the definition of page or component /apex/packagea__helloworld. Refresh your page and try again
Previous version = 3. Current version = 4.
Visualforce Page Conclusion after Upgrade. So it seems this is handled, much like in a developer org.
Apex Code Assumption. I suspect the Apex compiled code cache is version specific, so active requests will continue using the current version of the code until the install is commited. With the exception of the active VF page use case above. What I suspect your other question stumbled apone was an internal cache refresh failure (bug basically), doing the install and reinstall must have flushed it enough the second time. What perhaps could be done as another test is attempt an install during a long running Batch Apex job, one implementing Stateful interface.
Silent Failures, i can only answer based on my experience. It is that I have had failed installs that offer no email or feedback at all. Sometimes trying again works, other times if it is repeating I have raised a case with Salesforce, giving them the org Id of the Subscriber org and they have found unhandled exceptions from the install process in their internal logs. Most of which I've found to be valid errors that I would expect to have been reported (e.g. org config or limits exceeded). I've not had an instance of this for the last 2-3 releases as i recall. Maybe you've found a corner case still not trapped. It maybe be worth a case to have them scan the logs (if it was not that long ago), otherwise attempt to repo it and give them the time reference.
Hopefully this helps shed some light on it and give you some confidence at least for long running tasks your users are performing in Visualforce pages the system handles it.