Unfortunately, the #1 item in your two lists completely go against one another. You cannot have snow in summertime. You have to choose.
As for the conversation timing out, the simple solution here is to use a natural conversation (so that the request parameter has the information to perform a lookup) and catch the conversation timeout exception and requery. With some work, you can hide this. Your research could be helpful to others.
Thanks for the response Dan. I have been using a natural conversation id, and it works well in that a user can return to the same record and gets a cached set of data.
However, once the user conversation has timed out the user gets an error, rather than seam restarting the conversation as I would have hoped. I guess this could be debugged/resolved.
However, having thought about what the user needs, I think it's more important to have the latest data on screen and 'refresh from DB' type action on the screen is too hard to explain, so decision made to drop the long running conversation...