In theory and according to the OOP concept they might not be needed but when it comes to actually implement a OO concept it can turn out to be handy to have. That is, accessing a private member in the same module.
Allright. But I don't see a reason why this coudln't be done with nested classes. If some class wants frequently to access parent's members, then it preferably demands constant reference to it and therefore need to be presented as inner class. Then we can better and more intelligently track the existence and cooperation of both classes.
And, as it was said, there is no actual encapsulation unless you have organized runtime access checks to the memory chunk occupied by an object. Maybe the creators of D can implement this using contract programming or other things, I do not know. But this can be really a huge step towards safety. The real effect may be seen if the whole OS is written in object oriented manner, and its processes and services have the built-in hierarchical access policy. Such architecture makes possible natural cooperation between various core modules, processes and the user space. Maybe even existence in one address space without the need of slow artificial system calls.
If someone wants to continue discussing OOP, then I suggest to move to another thread to stop polluting this topic. Although I think that there are enough debates around OOP in the Internet already and yet another one will not make difference.
