> On macOS and iOS, it’s not just built into every app, it’s built into the operating system itself.
I can't see how it's any more part of "the OS" in MacOS than in Windows?
> On Windows, apps need to implement this behaviour manually. Figuring out how to deal with certain file types is not built into every app out of the box.
Every app on both Windows and MacOS have to implement most drag & drop handling themselves. You get notified that the user has dropped some data, and you implement it.
Some controls are basically miniature apps and can handle some of it (e.g. a text control could as default accept dropping text into it) but that's a rare edge case and in most situtaions you are obviously going to have to implement it yourself. If you are the audacity developer you'll be notified that someone dropped an mp3 on the surface of your window. You'll have to take it from there. That's 100% the same thing in windows.
> drag a image file from Finder into a Word, it should embed the picture; drag an audio file from iTunes into an open Audacity project, it should add the audio as a new track; or, drag highlighted text from a text field to the desktop and it will create a text snippet file containing that text.
File drag events work like that on windows. Text selections aren't objects in that sense (dragging just changes the selection) so that's typically not a draggable entity.
A picture is, and behaves like you expect (e.g. insert into a word document).
> I’d actually just drag the file directly from the Downloads stack on to the app and expect it to figure out what I want to do
Of course, a chat app has drag and drop for pictures into chat messages on both windows and mac. Otherwise it would be a pretty terrible chat app. Any cat app could of course be terrible, and there is every chance that more chat apps are terrible on windows - but that doesn't change the point. If you launch Teams or Slack or whatever and drag a picture from a word document into it, it will add it to your chat message. On both windows and mac.
> So, imagine I have a browser window open asking me to upload a file. If I have that file open, why should I navigate the directory hierarchy in the open panel? I can just drag the proxy icon for that document straight into the open panel. Bam, the open panel is pointing at the correct location.
As a windows desktop developer myself (who struggle a LOT with drag & drop) I can see myself implementing something like this. But it's always a question of user expectation. First of all, there is no proxy icon! I'd love to see those in windows, but it's not currently part of the UX. As such, you don't have a "drag source" for open documents. To get anywhere to drag from for an open document you'd need to open explorer and browse to the location. But that's the exact same effort as doing it in the file dialog, so what's the point? As you can see, the mistake wasn't "poor handling of drag & drop" here, the missing capability I think is the proxy icon.
> All I’m doing is telling an open/save panel where I want to be.
I want to repeat - and this is important. The windows save panel isn't special. It's a full explorer file list, plus a file name textbox. One can argue that this is a poor choice - but that's what it is. It has different areas (a filename textbox, a file listing view etc). The file listing view is just like any file listing view in any explorer window. As such it has all the capabilities you expect. If you select a file and hit delete, it's deleted. If you want to create a new folder - perhaps the most common operation for a SaveAs dialog, it does that. So here microsoft had a choice: if you drag a file onto this area of the dialog, should it work like all the other explorer file listing areas in the OS, or should the Open/Save dialogs have special treatment? I think you could argue both ways there, but there are definite drawbacks to both. It's absolutely not a clear cut case of "Well that dialog should be non-destructive so dropping should do navigation! case closed!". This doesn't mean you can't have that functionality anyway. You could just make a drop of any file elsewhere on the dialog (such as on the path-section of the dialog) initiate a navigation, for example.
> The only thing I expect to act as an Explorer window is … an Explorer window.
I think this is merely a UX choice not a clear case of "well this way is better". As I said there are several types of file dialogs in windows, and some are more like what you describe and not "Just an explorer window".
Perhaps if windows had proxy icons, there would never had been a thought to make the latest gen file dialogs be full explorer views, because then the proxy icons would have made drag to navigate work?
I use both windows and mac today, but growing up on windows, I use MacOS less and I use it like I would use windows. Which means it's extremely frustrating. For example, I had no idea whatsoever that the little icons in menubars (I just learned they were called proxy icons) were draggable. I always launch finder like I would launch explorer and drag things around, even documents I already had open... It sounds to me you have a few such discoveries to make on windows which would make the experience less frustrating.
