There's a reason why Microsoft didn't use SourceSafe internally, it was an awful version control system even compared to what else was available at the time (CVS and whatnot). For example, it didn't support the concept of "atomic commits". If you tried to commit multiple files at once and one failed to merge, the repo would just update the files that successfully merged and then the developer would have to fix the conflicts and try to commit again. Additionally, if you deleted a file, it would give the option to "permanently delete" it. If you checked this, it would completely remove the file from all past commits. VSS would also randomly corrupt files and the way to fix this was by permanently deleting the file from the repo and then re-adding it. The combination of these factors meant that VSS could not reliably show what the state of the codebase was at a given point in time, which is one of the main reasons for using version control in the first place. I sometimes do software archival work and it's fairly common that you'll find a VSS repo for a project and then you can't compile any commits older than a few weeks because of missing files.

SLM was at version 1.5 by 1988 and looking at chapter 5 suggests it had strong version number and external release management [1]

[1]: https://fpga.org/wp-content/uploads/2023/09/SLM-1.5-Guides.p...

When I used visual source safe it was primarily more like a lock manager. I don't recollect what it did in terms of file versioning, but I definitely remember having to bug someone to let go of a file I needed

That's what it was, wasn't it? You checked out some files and that locked them against other changes, then when you were done you checked in.