DDS12 — Behavior of dispose with regards to DURABILITY QoS

In Section 2.1.2.4.2.13 (dispose) it states "in case the DURABILITY QoS policy is TRANSIENT or PERSISTENT, the Service should take care to clean anything related to that instance so that late-joining applications would not see it".
Is this really necessary? Is it not acceptable to allow late-joining readers to see an instance with the NOT_ALIVE_DISPOSED instance state?
Does this also apply to TRANSIENT_LOCAL?

We think disposed instances should be propagated to new-ly discovered applications, otherwise there would be no way to enforce ownership of a disposed instance.
Furthermore the application should be notified of disposed instances even if this is the first time the middleware sees the instance because in practice there is no way for the middleware to tell if the application has seen the instance already; for example, following a network partition the middleware may have notified of NOT_ALIVE_NO_WRITERS and following the application taking all the samples it could have reclaimed the information on that instance, so when it sees it again it thinks it is the first time; the application meanwhile could still have information on that instance…
So the user case where a newly joining reader wants to not receive instances that have been disposed before it joined should be handled on the writer side by either explicitly unregistering the instances, or having some new QoS that auto-unregisters disposed instances.

Another issue is whether the act of disposing on the writer side should automatically remove previous samples for that instance, and whether that is done for particular values of the HISTORY (e.g. when it is KEEP_LAST only, or KEEP_LAST with depth==1, or, even for KEEP_ALL). Seems like the control of this should be another QoS on the WRITER_LIFECYCLE.

Proposed Resolution:
For now eliminate the following text from Section 2.1.2.4.2.13 (dispose)
"In case the DURABILITY QoS policy is TRANSIENT or PERSISTENT, the Service should take care to clean anything related to that instance so that late-joining applications would not see it".

Proposed Revised Text:
Section 2.1.2.4.2.13 dispose
Remove the paragraph:
In addition, in case the DURABILITY QoS policy is TRANSIENT or PERSISTENT, the Service should take care to clean anything related to that instance so that late-joining applications would not see it.

see above