The more I think about this, the better I like it. If it’s a simple flag, there should be almost no performance hit to checking it when a file is loaded.
Like it or not, the more standard/usual/ubiquitous optimized storage becomes, the less acceptable users will find it that Scrivener can’t deal with it. So far as I can see the only path is the one that makes Scrivener somehow take these things in stride — by which I mean makes it work in that environment.
My guess is that the fix for this particular problem has already been drafted. Scrivener 4 anyone?
gr
*) Optimized storage solutions mean to detect file requests and to deliver them on demand. Why does this not work with Scrivener? I suppose the answer must be that Scrivener is using a file access function call that operates below the level at which the optimized-storage-deliverer is wedged in — so the deliverer doesn’t even know Scriv wants the file. And Scriv has no fallback defenses for the fail, because back when the code was written it was assumed that the package files would only be touched by Scriv and so there is no double check with the OS to see if the file being requested is just an alias. These seem like fixable issues. It just takes time.