Shapes do not stay in given z-order after save and open

[wapperdude]

I tried a couple different things, most failed.  But at one point in saving, Visio asked if I wanted to preserve Z-order.  I said yes, but that made no difference.  So, the clue is in the saving process.

The only, and very ugly, work-around I discover to be effective was to ungroup and then re-group.  That did save correctly.

Would be nice if anyone else would try and verify this loss of z-factor when adding shape to group.

[wapperdude]

Final note:
I was able to narrow this down.  If you drag and drop a grouped shape from a stencil, then add another/replace a shape to the group the "new" shape appears on top.  That's normal.  You can then subselect into the group and move the shape to the back.  This again is normal.  Save the document.  Close the file.  Re-open, and Viola! the z-order is incorrect.  The new subshape is at the very top visually.  Ergo, the problem.

Had the dragNdrop group been ungrouped and then regrouped (this is typically a bad idea/thing to do), then add new shape, send to back.  Repeat save, close, open, and all is well. 

I don't recall this being a problem in the past.

[Paul Herber]

Defo reproducable here in Visio 2016, but in V2010 it's ok.
I took one of my large grouped shapes, placed a rectangle next to it, selected all, added to group. In the Drawing Explorer, found the added shape (Sheet.26 in this case), Send To Back, saved file in VSSX format. Reopened file. New shape is back on top.
Had a look using my Utils -> Grouped Shape Report.
When the new shape is added to the group, it becomes Sheet.26 and is the last shape in the grouped shape list report.
Send to Back: report now shows Sheet.26 in position 1, i.e. it has been sent to back.
Save, Reload ...
Report now shows Sheet.26 back to being the last shape in the grouped shape list.
Now repeat in V2016 but save in .VSD format. All is ok. It is the VSDX format save that is &%£@*&$  wrong.

[wapperdude]

@Paul Gerber:  totally awesome dude!!!

[wapperdude]

Interesting addendum to Paul's findings. 

First, I confirmed that VSD does get it right.  But then, resaved the VSD file as VSDX.  Right?!?  After all, the VSD is now correct.  Busted.  The VSDX file still gets it wrong!!!