I've noticed inconsistent behavior when we have properties on the work page that reference editable data pages.  A few of the problems are defined below.  In all examples, the data page is defined as a list based data page.

• If the one of the .pxResults items in the data page has list based data, if I remove a page of that data (ex: D_TheEditableDataPage.pxResults(1).SomeList(4) is removed, the data page shows this as being the case, however the property referencing that data page does not recognize the change.  The property would look something like this pyWorkPage.TheReferencePropertyList(1).SomeList(4) exists but has nothing but null properties on it.
• Sometimes due to page-copy or page-merge, the property referencing the data page may get duplicated.  When this happens, the property list has extra items in it, however the data page remains correct.  Because of this, we see index out of bounds errors when referencing the list, and may also see rule not found exceptions because the null page being referenced has no  true pxObjClass.  This issue in particular seems to happen when we reference when rules that do checks such as @IndexInPageListWhen("SomeWhenRule", .TheReferencePropertyList). 
• Doing an obj-sort on .TheReferencePropertyList().SomeList does not seem to take effect.
• Performing a page-copy to append items to .TheReferencePropertyList().SomeList(<append>) seems to behave differently than doing so directly onto D_TheEditableDataPage.pxResults().SomeList(<append>) does.  Using the property-set method to append and then map seems to work when referencing the data page, which is what I've done to work around the inability to use page-copy.

For simplicity, I would like to be able to reference the property instead, however at this point I do not trust the functionality.  Is this something that Pega has noticed internally?