Funnily enough, I'd compare the image and versioning differences to managing Postgres rather than non-image based languages.
Postgres has to deal with images (backups) and versions (migrations). Maybe selling image-based systems in both cases needs a little work or formalisation (best practices and all that)?
Image-based systems seem more about data management rather than code management. Just some random thoughts
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users."
1984 "Smalltalk-80 The Interactive Programming Environment" page 46
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
Postgres has to deal with images (backups) and versions (migrations). Maybe selling image-based systems in both cases needs a little work or formalisation (best practices and all that)?
Image-based systems seem more about data management rather than code management. Just some random thoughts