...
Below is provided proposed storage-api "core" subset class/interface diagram, considering previously described changes (except last one). Interfaces are prefixed with "I" which will not necessarily be used in implemented interfaces. 
Observations:
- Diagram is "symmetric" till some level, since similar apis can be used for both StorageProperty and StorageBinary management.
- Like "current" DSpace 2 storage-api, proposed solution also separates read-only and writable storage interfaces.
- Service naming is used for interfaces.
- After changes to storage-api, StorageEntity class basically contains only entityId, so it is proposed that it should probably disappear from model or be used only as a structure (container) for properties, binaries, id(-s). This also solves entity versionability question, since properties essentially can have versions, not the entities themselves. In this case, IEntityStorageService IEntityStorage becomes entity identifier (simple string) management service.
- IMetadataStorageService IMetadataStorage (and its variants) is a service for management of both - metadata and relations.
- IBinaryWritableStorageService IBinaryWritableStorage method saveBinary(...) like saveMetaProperties(...) creates or updates property/binary depending whether it exists or not. Of course, these can be split into create and update methods if needed.
- It should be noted, that final property/binary storage implementation will have to store not only property/binary value and its name, but also entityId. Name and entityId could be combined into one name, however it is left up to implementation.
...