This happens because the modifier is being re-calculated while the dupli-object is drawing.

Drawing a dupli-object overrides the objects matrix, so when draw_mesh_fancy() calls mesh_get_derived_final(), the modifier stack is re-evaluated with an incorrect matrix.

The mesh_get_derived_final() is recalculating the stack because the view drawing datamask changes.

Possible fixes:
- don't calculate the modifier stack on draw, better design and means we avoid future problems like this.
- make sure mesh_get_derived_final() runs before the matrix is overwritten (though not simple to know if this will be called).
- delay overwriting the object matrix (pass the matrix as an arg and always use the obmat for modifier stack).
- store a second matrix in the object or allow it to access its original matrix.

The customdata mask should be computed from the open 3d views, doing derivedmesh recalculations means derivedmesh will always be computed twice, and it's not reliable because it's not done in the right dependency graph order. In 2.4x there was code to compute this customdata mask in object_handle_update, I think something similar should be added back in 2.5.

I don't know if it can help. Campbell seems to have identify problem.
But I am not sure if what I noticed is a well-known consequence or if it can help to precise problem.
So, I comment.
Displayed Mesh Data for every group instance correspond to what would be normal Mesh Data if Monkey was at the location of the last created instance.

fixed r34284.
there were 2 problems.
1) until recently the viewdatamask was not known when updating objects before drawing.
2) the group's recalculation flag was not applied to the objects when updating group objects, so objects outside the view were not getting updated.

fixed by making group_handle_recalc_and_update() work like how it did in 2.4x. applying the recalc flag to objects in the group.

Ill try explain the problem as I understand it
* when an object is in a dupli-group its matrix is overwritten, the modifier stack gets built while the dupli transform is applied.
* This becomes unreliable if the object is in the viewport more then once since in that case the first drawn object has _its_ transformation space used for the modifier stack.
* When there are 2 or more duplis of the same mesh there is no right way to go about this, the first one's space is used.
* When the object is directly included in the scene as well as a dupli, the worldspace transform is used and the dupli takes on this EXCEPT when the object is not visible. This is the bug which is described.

I think the best way to deal with this is to add in logic which calculates the modifier stack for objects which are in the scene in worldspace even if they are first drawn as a dupli and are on a hidden layer, otherwise we get this problem where changing layers changes the modifier transform.
This could be done in 2 obvious ways
1) When drawing objects, even if the object is on hidden layer add ability to know if the object is drawn later as a dupli and calculate its modifier stack anyway (though its hard to know what _will_ be drawn later)

2) When drawing duplis tag objects which are directly in the scene and use this tag to known when to use the original worldspace matrix for calculating the modifier (This is more realistic however the objects currently don't store their original worldspace matrix, the duplis do but this can be changed and its simpler then option 1 still).

>>> ob-dupli is overwriting matrices is the bad thing
Agree, though we did make use of it for sintel when the sim could run on the dupli transformaion, but we should really have some better method to get the same results.

>>> apperently textured draw is going via a different route,
its not, the change of draw mode just triggers a modifier recalc because the existing derived mesh has no UV coordinates since they were not required on solid mode.

I suggest we give up on this to work well. It's a design issue that shows the weakness of blender handles display data for duplicated objects.
Best I can do is to add this report as a reference to the list of issues that have to be solved by the "Depsgraph" recode project.