We have run in to several instances where the Office Web Apps will not redirect back to the expected library.
This is caused by a difference in code behind the SharePoint 2010 document library and the SharePoint 2013 document library.
Here is an example situation in a SharePoint environment which has both 2010 sites, and 2013 sites.
-User navigates to a SharePoint 2013 document library.
-User clicks on a Word document, which launches the Word web app in "Read" mode.
-User decides they want to edit the document in the Word client.
-Word client is launched in edit mode
-Meanwhile the browser which was displaying the Word web app has automatically navigated back to the original SharePoint 2013 library.
-User finishes editing the document in the Word client, then saves and closes the Word client.
-User goes back to the browser, which is still on the SharePoint 2013 document library
-User navigates to a SharePoint 2010 document library
-Again the user selects a Word document, which is opened in the Word web app in "Read" mode.
-Again the user elects to edit the Word document in the Word client, which automatically redirects the browser.
-This time the browser redirects back to the SharePoint 2013 library which the user had previously visited, rather than the SharePoint 2010 library which they navigated to most recently.
When the browser opens up any Office Web App in a SharePoint 2013 environment (on premises or Office 365), it loads the "WopiFrame.aspx" or "WopiFrame2.aspx" page. This is the page which gives all Office Web Apps a place to display documents.
The "WopiFrame.aspx" or "WopiFrame2.aspx" page depends on the "WOPISessionContext" cookie set by SharePoint to understand where to go when the Web App page needs to be redirected.
In a pure SharePoint 2013 environment, users will not run in to this issue because there is code behind SharePoint 2013 libraries which updates the cookie every time you navigate to a new list/library.
This code does not exist in SharePoint 2010, which is why the "WOPISessionContext" cookie does not get updated, thus explaining the "incorrect" redirect from the "WopiFrame.aspx" or "WopiFrame2.aspx" page.