It makes sense if one considers the angle of how single-key shortcuts are much more disaster-prone.
For example, if the user has a large number of files selected and accidentally triggers the open shortcut by hitting enter, their computer is going to be stuck spinning its wheels for a while (the more files involved and the heavier the applications they open in, the worse it'll be) unless they force restart. Involving a modifier key filters for intention pretty well, and so while this scenario is possible with ⌘O, it's far less likely.
Most Mac shortcuts seem to follow this, with those that are single-key by default doing relatively harmless and easily reversible things.
> It makes sense if one considers the angle of how single-key shortcuts are much more disaster-prone.
> ...
> Most Mac shortcuts seem to follow this, with those that are single-key by default doing relatively harmless and easily reversible things.
The enter-to-rename behavior has been in Mac OS since near the beginning, when versions were just named something like "System N.M").
IIRC, I've heard they had very detailed UI design documents back then, that explained their choices (e.g. I've heard they explained the reason for the menu bar being at the top of the screen rather than the top of a window was the cursor will just stop there, requiring less mousing precision).
So if that's the case, there should be documents confirming or denying your speculation.
For example, if the user has a large number of files selected and accidentally triggers the open shortcut by hitting enter, their computer is going to be stuck spinning its wheels for a while (the more files involved and the heavier the applications they open in, the worse it'll be) unless they force restart. Involving a modifier key filters for intention pretty well, and so while this scenario is possible with ⌘O, it's far less likely.
Most Mac shortcuts seem to follow this, with those that are single-key by default doing relatively harmless and easily reversible things.