Memory Backend Implementation

We should discuss what the rationale behind a memory backend would be to decide about its implementation.

The "memory" characteristic could serve two features:
-speed
-easier to implement if done from scratch

it would IMHO _not_ serve:
-usability as "simulated dialog" / as storage for synchronization attempts

it would negatively affect:
-thread safety

Remarks: I do not think that temp-storing data somewhere (like a simulated dialog form or a temp copy for synchronization) requires having it in the memory for other reasons than speed. In our special context in fact we could easily use any backend implementation to temp-store another (e.g. "HDF5" backend stores "POSTGRES" backend).
Regarding thread safety: having a HDF5 file on disk is safer than having just a FILE frontend object in memory, which is thread specific currently.

All this just as prelude for the question: how should our "memory" backend look like? Should it really be a "memory" storage?
If so, jgrewe proposed a very interesting option: does HDF5 support storing data in memory? In this case one could simply re-use the HDF5 backend.
Disadvantage: not having an independent test backend that e.g. circumvents the HDF5 specific getter, setter, "group", "hydra" and hdf5-structures.

What are your thoughts?