Mike, I consulted with Oren about this and you have a misunderstanding about how the viewer works. The way it works when it connects to a server is (I'm leaving out parts that are irrelevant to object rezzing and simplifying some of the steps):
1) Query OpenSim for a list of the objects that are rezzed in the sim (i.e. the list of objects in the scene).
2) The list the viewer gets includes objects and the assets they reference (using asset UUIDs). Those assets can include meshes, textures, etc.
3) The viewer then goes over the list of assets and checks which assets are not already in its cache. It then starts requesting those assets that it doesn't already have from the asset server (it does this in stages as some assets have LODs that are downloaded separately).
4) Once the viewer has downloaded the minimum LOD levels it needs to render a certain object it uses them to rezz that object while it continues to download higher LODs for those assets.
The viewer uses the Viewer Object Cache mechanism that Second Life developed, that is included in Firestorm and that Ubit added support for in OpenSim. It is quite complicated and involves a viewer-server protocol that has bugs in OpenSim 0.9.1.1 and the viewer. We were forced to disable the server-side part of this cache on Kitely (it's an OpenSim.ini setting: "SceneObjectGroup.IsViewerCachable") to overcome some of the bugs we found that we couldn't fix without making changes to the viewer (see:
viewtopic.php?p=26884). The memory-based parts of the Viewer Object Cache mechanism are only valid for the current session and uses time-to-live information to decide when the viewer needs to check the object again even in the current session. The memory-based parts of this cache are cleared when you close your viewer but there is a separate disk-based cache where the viewer stores the assets that the objects reference and the viewer object cache itself may have a disk component as well (it's been years since we looked at that viewer code).
Now let's look at the scenario in your last comment:
1) You entered SPACE FORCE and the viewer got the object information from the object that includes the mesh and the textures it references from our server. It's possible it got them from the Viewer Object Cache instead of contacting our server again if you rezzed the object in SPACE FORCE in the same session you got it from Naboo or within the same hour (I'm not sure about the details as the last time we looked at the viewer code to try to debug issues with this cache was years ago and it's likely this mechanism has been updated since then).
2) Your viewer then loaded the asset files that belong to the assets that this object references from the viewer disk cache that had already stored them during your visit to Naboo. Note that the viewer didn't need to contact our assets system again to do so. As it had the object and the assets data it needed it could render the object without doing so.
3) The next time you visited SPACE FORCE after you restarted your world the viewer needed to contact our server again to get the object information but not the asset data (that remained stored in your viewer cache). However, it didn't use the information that it got from the server to render the object properly. Only after you interacted with the object again did the viewer change what it rendered. Oren's guess is that the problem is similar to the one we encountered years ago where the viewer "forgot" object properties until it was forced to "remember" them after receiving an ImprovedTerseObjectUpdate packet from the server that caused it to update its internal object cache.
This is a viewer bug Mike. A bug that is possibly effected by how OpenSim implemented the Viewer Object Cache mechanism protocol. A mechanism which we disable on Kitely using a standard OpenSim.ini setting to eliminate the various issues that it creates in OpenSim 0.9.1.1.
As a last note, I've now spent hours dealing with your complaints in this forums thread. I've addressed all your complaints with detailed information and without delay and you continued to throw accusations my way about how bad I'm supposedly treating you or how I'm oblivious to our customers' concerns. That's uncalled for and isn't helping your cause. We're not going to debug viewer code again, the solution lays with Firestorm devs. If they ask us for it, I can give Beq our findings from our investigation of similar issues when we upgraded to OpenSim 0.9.1.1.