So the Binder is essentially a mini-Finder, but I’ve never thought of it that way. And yes, I read the Manual—for Scrivener 2. Did the tutorials, too. When ver. 3 came along, I was (still am) deep into a very large project, so if this is made clear in the current manual, I missed it.
And to be quite clear, that impression is intentional! We go out of our way to avoid drawing comparisons between Finder (or more accurately, the file system) and how the binder or the outline view in Scrivener works, and actively try to push other metaphors. In other words I think your first impression is the best and right hunch. It’s an outliner, like OmniFocus, Tinderbox and other such tools where information is expressed hierarchically in a collapsible node tree. True, a file system owes some of its metaphor to outlining, but there are important differences (not relevant to this discussion I would say).
Now as for standard mouse clicking behaviours among outliners, that’s a bit more difficult to say, because there are so few of them and hardly any of them act alike. When I said that the type of view we use is likely using Mac standard behaviour, I meant it in a very technical sense—not one of behaviours typical to software overall, or even a specific software genre. In other words when you create a tree view using the programming tool that we use to draw it as you see it on your screen, it comes prepackaged with behaviours for double-click and such. Unless you change them deliberately, they are ipso facto Mac standard behaviour.
And so to that end…
All that said, I still think there may be a timing difference between the Binder and the Finder. It wouldn’t take much, but is it worth the effort to find out and change? For me, if I were writing the code, probably. For those who are writing the code, probably not.
There is often a risk in doing that. If you override a default behaviour, then if later on Apple comes along and changes something that depends upon the assumption of default behaviour happening elsewhere, then your customisation becomes a bug. Hence the more you do this, the greater the likelihood of having to spend most of your days fixing bugs introduced by yearly Apple overhauls to whatever they consider to be “modern”.
It’s worth looking at, to be sure, but there are good reasons to not customise everything in sight—even if it makes good sense to otherwise.
Hopefully that background information is insightful to what you’re seeing.
Oh, and by the way: the main point of variation that I saw between your description and most other Mac tools I tested against is that if you are clicking so fast that the third click is not separate from the second click, then that sequence is treated as a double-click: the result is to select a word within the now open editing field. If you click slowly enough that double-click behaviour is not triggered, then it places the cursor (and does in Scrivener as well). I didn’t see anything with an actual triple-click behaviour that does anything special from an unedited state.
I just wanted to emphasise that if we can change this, and decide it’s a good idea to do so, it like still won’t work the way you asked for initially, because if you’re clicking that fast: it’s going to select the word under the pointer.
.
(I can no longer over-run the keyboard buffer.) I’ll just approach it as I do in the Finder, and it will be less aggravating.