Pretty sure the open file dialog being read only is a feature and not a bug - you also can't move things around, delete things, etc. I actually like this b/c when I want to find a file, I don't want to move something accidentally. It also lets them implement things like dragging a file from Finder to open dialog to select it (that feature doesn't make sense if your file pickers can also modify the files).

The point wasn't that having a read-only open file dialog is wrong. It's that that having a read-only file dialog and a full-featured file browser look identical is confusing/misleading.

Rather, it's that you got used to renaming files in an open file dialog from when you used other OS's and you now expect it to work like that.

Logically, an open file dialog should be read only since the task you're trying to achieve is just to open a file, not rename one. This means no accidents etc. And if you've ever seen my Mum open a file, you'll know accidents happen all the time ;)

I've seen enough novice users inadvertently move or rename files in the Windows save and open file dialogs that I'd call that a feature.

The open file dialog is exactly that to "open" a file. I find the fact that you can do that on Windows stupid and inconsistent.

You find it normal that two windows that look exactly the same don't behave the same way depending on how they were invoked?

This violates a concept at the core of basic GUI design called "The principle of least surprise".

I regularly want to do file operations when I open file dialogs, like noticing some garbage file I forgot to delete or wanting to rename things. Having to launch a separate Finder just to do that on Mac OS is a constant reminder how it's an operating system stuck in the early 2000s.

I can see your point, but Finder looks nothing like an Open dialog. Sure, the Open dialog has a list of files in it but it doesn't feature tabs or a corresponding menu at the top of the screen to allow you to connect to servers (eg screen sharing). They're clearly two different things. I have never seen anyone confused by it. I have seen people more confused by the fact that "renaming" under Finder is done using ENTER! I would expect Enter to open the file but apparently Cmd-Down is the obvious choice...

I would say the cluttering up of Windows Explorer is far worse though: it now features a giant useless blue bar (which you can't hide) at the bottom in addition to the statusbar (which is hidden by default), a list of directories on the left in addition to favourites and libraries (all to confuse users so they have no idea where anything is, you should see my mum trying to use it), left and right panes that no longer correspond for navigation (you can navigate with the keyboard in the left tree but the right pane doesn't follow it), a menubar BENEATH the toolbar, an additional toolbar for operations (why aren't these inside the other toolbar?). The list goes on! I know this is under Windows 7 and has likely changed in 8+ but post XP it has really gone downhill.

W-a-a-a-y back in the mists of time, during the MacOS days, it was recognized that Macintosh power users wanted even fewer context switches than the Macintosh was already delivering. There were hooks that allowed savvy software companies to create extensions to the MacOS file dialog, which allowed just exactly what you call "stupid and inconsistent". For users who wanted to work as much as possible through the GUI via the keyboard, these file dialog extensions allowed a lot of customization to workflows. These customizations were apparently popular with the graphics artist set; when I spoke with some of these folks out of curiosity (since I agree with you that cramming these features is wildly inconsistent with the Mac design principles, but an awful lot of them were buying these packages from me at the time), it turns out that it was a very practical way to wrangle lots of projects and lots of files in each project going on at the same time.

It was a variation of the highly customized key bindings you see lots of vi/emacs/terminal users create, often by those who deal with workflows that have a repetitive aspect, but not repetitive enough to automate. It just so happened these key bindings were all in the file dialog. Since these were primarily graphics artists who I found were the most vocal about these customizations, it totally made sense to me then why they wouldn't be living in emacs and customizing that instead. Mostly actions like "jump to this folder", "copy this filename", "search in this folder", "recursively search from this folder", "serialize these filenames", etc. Very edge case activities compared to mainstream GUI users, but it turned out immensely useful to this subset of users; literally saved them up to an hour per day, which added up really fast.

I sometimes wonder if they weren't onto an aspect of GUI development that seems to have languished in recent years. There used to be a sense in GUI design development of an incremental, iterative progressive disclosure of GUI features to accommodate neophyte to expert users alike, and slow down no one in that entire spectrum of operational expertise and/or desire to manage complexity. The Windows and Mac GUIs these days seem to be far more monolithic in how they treat the user spectrum (Windows a little less so, in that there is more room customization, but I don't really see a lot of users adopting the available customization software), and seem less layered and nuanced. I'm sure this reflects really well upon vendor support costs, but some days I wonder how we can bring to the mainstream GUI-oriented users the deep customization benefits that we programmers take for granted on our text-oriented tool suites.

At the same time, the KDE and Gnome environments allow this kind of customization (and then some), and they haven't really taken the mainstream GUI world by storm either, so I concede that this might easily just be a worse is better situation, and the kind of advanced GUIs we programmers think are cool are simply not practical for everyday users.