The concept of Rooms, Items and Zones has been replaced by a generic concept of Spaces, which can be simply viewed as smart or rich folders. All containment (rooms, zones, folders) is managed through Spaces. There is no longer any distinction between Document Libraries and Zones with Files in - there are just Spaces that can contain further Spaces or Content.
Each Space has an owner that can make any changes to the Space or its immediate contents. A user in the system will usually (but not necessarily) have a Home Space, which they can organise in any way they like - they are the owner of that Space. A Home Space will contain a special system-managed Space (usually hidden) that contains any meta-data or content for that user, e.g. tasks. Home Spaces can be defined anywhere - which can make moving people or whole teams into different structures straight-forward. This is very like the Unix approach, but without the convention of storing all homes in a single location.
The owner of a Space may invite another user (or Team?) into the Space with a specific role (e.g. viewer, contributor, administrator). When a user is invited to a Space, they are given the option to create a shortcut to it (by default somewhere in their Home Space).
Once a Space shortcut is defined, it is possible for additional meta-data to be defined for it that personalises the interpretation of the linked Space, for example, changing the default view for the Space (but obviously not any permissions or capabilities).
It should also be possible to create a shortcut to a Space in another repository. The main issues this raises is how search is performed (federated query or crawling) and access to meta-data such as the data dictionary.