In other words you're saying that "the browser stores it's state, not the Mink, that we're using to control it". Then the Mink is the low level browser controller (on top of driver-set) and doesn't really care about stuff in browser, unless developer would use it's methods to access it.

How then you can explain the fact, that PageObject is implemented in Selenium is just a browser controller (see https://code.google.com/p/selenium/wiki/PageObjects), like a Mink?

In general the PageObject implementation in Selenium is controlling the way how PageObject classes are instantiated based on urls. It doesn't really store any state either. There, for example, instead of visiting an url directly you're instantiating PageObject subclass of needed page and call `->open()` method on it. Then any action, that might result in redirect to other page is wrapped in a dedicated method (e.g. `->submitSearchForm()`), that will return a subclass of the page where will will be redirected to.

The `WebElement` class is Selenium is must alike to `NodeElement` class in Mink, but there is no analog to Mink's `DocumentElement` class in Selenium, because there is no common parent class to all PageObject classes there. This proves that `DocumentElement` is correct start for creating page objects.

Besides we're having same problem (as with multiple `DocumentElement` instances) with PageObject's as well:

```php
$page1 = new PageOne();
$page1->open();
// do actions on $page1 page

$page2 = new PageTwo();
$page2->open();
// do actions on $page2 page
``` 
At the code end we end up on `$page2` page and sadly `$page1` object, regardless of it's class, will operate on $page2 page as well.

So the fact, that `Session::getPage` method might create new `DocumentElement` subclass to represent currently visited page doesn't seem so bad after all.

Maybe this can be solved somehow, but I can't imagine how exactly right now.