org.eventb.emf.core.impl.EventBElementImpl.getElementIdentification() generates a UUID and sets internal ID on the element if it is not already set. This side effect can be a problem e.g. if the element is in a transactional editing domain. Maybe it would be better to always initialise all elements with a UUID
(n.b. we might restructure the Event-B EMF anyway)

The Event-B EMF meta-model does not support ordering amongst children from different containments.
E.g. with the new records extension, we might want to place some invariants before records and some after records.

The meta-model could be re-structured with a single children containment. The current containment features can be supported as derived features. N.b. it might be possible to extend the Systerel 'EMF-lite' meta-model (used by the Rodin editor) to achieve this. This might also simplify the current persistence.

EMFRodinDB assumes you want a transactional editing domain. This is a problem if you don't since any changes are notified and must be wrapped in transactional commands. It would be better to provide some static utils for loading etc. without assuming full transactional editing is wanted. The current API will be deprecated for now and new static util methods added instead.

Q: Shall we put these static utils in the utils class and redevelop the EMF Rodin DB with the current util methods that are wrapped in commands?