It sounds like you are referring to how some applications work with individual documents you open, like Scapple or .txt files—i.e. simple formats that can be loaded entirely into memory at once and operated on purely “off disk” until you choose to save the file (or not). There really isn’t much of a comparison between formats like that and a program like Scrivener. I just tried three other programs that work more like Scrivener, where one loads a container that houses potentially thousands of files and only loads into memory the ones you work on within that session, and out of all of those, none of them had some kind of overarching “Are you sure you want to quit without saving changes?” when closing the container/database/etc.
It is (a) not a feasible mechanism for this kind of software, and (b) there is no infrastructure for it on the Mac even if it were. So we aren’t “overriding” anything, and we aren’t doing anything terribly out of the ordinary for this kind of software.
I will agree with you that locking would be nice in Scrivener, and it isn’t uncommon to find locking in database style programs—but it is a little more complicated than you seem to be thinking it would be, and of the one example I tried that is very much like Scrivener in this regard (Ulysses), it works exactly the same, with no locking.
Consider for example if you have one locked paragraph in a 100-item Scrivenings session (or a section of sheets in Ulysses). What happens then? Is there an immutable chunk of text in the middle of your file? If you change the font wholesale on that 100-item chunk of text, are patches of it ignored if locked? That could result in some embarrassing mistakes down the line if you thought the font was changed and never noticed until a reader wondered why there was suddenly a Courier paragraph in the middle of the book. Or what if you loaded that chunk of text with the intention of bulk search and replacing a character name? These are not challenges that a more typical database style program has to face—where one doesn’t consider chunks of text in the outline to be smaller ingredients in a longer span of text. It’s probably not an impossible problem to work around, surely, but I have a difficult time visualising an elegant approach to these problems.
Theory aside, here’s what I do to have peace of mind: switch on the Take snapshots of changed text documents on manual save setting, in the General: Saving preference pane. Using manual save is already a bit of a habit for me because I also make use of the Back up with each manual save setting in the Backup preference pane. When I’ve done a chunk of work and I’m happy with the state of everything I’ve worked on in that session, I hit ⌘S and in doing so I get every single file I’ve touched backed up individually with snapshots, as well as the project structure and content as a whole.
There is nothing convoluted about that to my mind—it is in fact precisely the same sort of mechanical action/reaction you get from a single-document based application where when you save a file that’s your last anchor point set. I don’t have to think about these snapshots, I never do, and when I need them they are there.
The only downside to that approach really isn’t much of one in Scrivener 3. In the past it meant a proliferation of hard to clear out snapshots. The snapshots still proliferate of course—that is what we want after all—it’s the clearing of them that is now easier: the Documents ▸ Snapshots ▸ Snapshots Manager feature makes it a simple affair to purge these old automatic snapshots across large groups of documents at once.