> ...version system build into the VMS OS file system.
That was more of "versioning" than "version control" system. It simply automated the sequential numbering of the saved instances of a file. The versions were not deltas, just normal files, the version number being part of file specification:
name.ext;ver
As much as one can do with versions was diff, purge and file operations, basically, no change annotation or higher level grouping. But being files, the versions allowed to see the what-who-when changed. No why. Still this probably was convenient in some use-cases and as an immediate file backup.
As for the real version control system on OpenVMS, one of such was called CMS, part of DECset suite. I believe it was of exclusive-check-out/check-in kind, similar to how it's done with, say, CVS, but absolutely not like CVS otherwise. For example, there was no support for directories in the repository.
I guess these days it may be possible to run Git on OpenVMS too.
CVS was not of the exclusive-check-out/check-in kind, it would merge by default on "cvs update", this was one of the main differences between it and RCS or sccs. The other main difference was it had a network protocol and didn't rely on the filesystem for sharing (e.g. NFS and the like). It was probably this 2nd difference that enabled it, (and subversion), to overtake RCS and sccs in the 90s.
I always wondered if Common Lisp pathname versioning could be leveraged intentionally when pointing at files in a git repo, to reference older versions of that filename. (And whether that gives any utility...)
You'd have to violate the standard a bit (version is a positive integer and :newest refers to the largest such in the file system). But I don't know that anyone uses it these days, so maybe that's ok.
But what was astonishing me most was the version system build into the VMS OS file system.