Hi Martin,
As near as I can tell, the reference will be kept until you go back past the page.
In a forward navigation, HistoryOrientedPageSession
seems to push a copy of all the <properties/> onto it's page stack before tearing down the view (and de-referencing the <locals/>). They'll remain referenced on the stack until such time as a back navigation to the page occurs at which point the view and associated <locals/> will be re-created and the and <properties/> popped off the stack. If the active page goes out of scope via a back navigation, then they're lost and eligible for collection. If it's a forward navigation, they're pushed on to the stack and remain referenced.
If you're worried you're not getting the behaviour you desire, the easiest thing to do is to add a finalizer that outputs some debug text and see when they're actually being collected.
Alternatively, you can consider implementing IModelItem on the class and assigning them an appropriate owner whose scope is linked to the behaviour you desire. That will give you some control over how/when they're disposed. You could consider letting the magic [View] named reference own them, since it implements IModelItemOwner and it should be torn down when the page is navigated away from in any direction.
In the general case though, the default behaviour will likely be what you're after: <properties/> are created when the page is displayed, and remain referenced until the page is no longer accessible (out of the history). This allows them to maintain persistent state for a back navigation. <locals/> are re-created for every display of the page. So, persistent, stateful objects as properties, transient, stateless objects as locals.
If it is a particularly heavy object that you want to create as a <property/> and dispose of whenever the page is navigated away from in any direction, you could consider adding a <default/> rule to create them, setting the owner property an appropriate IModelItemOwner in the UI. This way a new instance should be created each time the page is (re)displayed, and destroyed when the page is navigated away from. You'll need to be careful with this approach, though. The way object paths are resolved is sometimes to a hard reference on initialisation, and other times via a soft on-demand resolution (similar to early vs. late binding in some languages). This could mean you end up with hard references to a previously disposed version.
In almost all cases, the default behaviour should be fine. Just verify it with a bit of debug output.
As far as ensuring a call to Dispose goes, you can ensure it is called by adding it to your object's finalizer. You might want/need to track whether it has already been called before calling it again, though, or perhaps suppress the object's finalizer when it has been called (when/how/whether to do this varies depending on what you're trying to achieve). If you look at the documentation for IDisposable you'll see an example of this pattern.