Direct File Access doesn't seem to be behaving as I expected, with certain settings.
Maybe I have some kind of mental blockage on this, but I can't see why this is happening.
--
I first encountered this behaviour in sandboxed Thunderbird, but have found it occurs with Firefox also.
By setting up OpenFilePath settings, I intended for files with certain extensions to bypass the sandbox when saved.

For example, this has always worked for me in Thunderbird:
OpenFilePath=thunderbird.exe,*.eml
If I select File > Save As > File in TB, a *.eml message file is saved as an individual file outside of the sandbox, and no copy of that *.eml file is saved in a sandbox folder.

It's a different story when I try the same thing with other file extensions:
OpenFilePath=thunderbird.exe,*.gif
OpenFilePath=thunderbird.exe,*.jpg
OpenFilePath=thunderbird.exe,*.png

OpenFilePath=firefox.exe,*.jpg

After testing the above settings, what happens for me is that a file of one of these types is immediately saved outside of the sandbox, but a copy of the file also remains in a sandboxed folder.
If the files are saved to a Recover Folder, there is no Immediate Recovery prompt, but Quick Recovery prompts to recover these same files when the sandbox is deleted. Since they have already been saved outside of the sandbox, this results in a request to overwrite the files.

If the files are saved to a non-Recover Folder, a copy is still kept inside the sandbox but, of course, there is no Quick Recovery prompt.

Tested with Thunderbird on 3.48 and 3.49.08, with new sandbox and also after a clean install of 3.49.08, with a new configuration file.
Tested on Firefox with 3.49.08, my current configuration settings, and also in a new sandbox.

I can reproduce the problem, so I'll look into this and post my findings, hopefully tomorrow.

What I see happening is the browser opens and writes into the following file

C:\OpenFolder\NewImage.png

then it opens and writes into the following alternate data stream,

C:\OpenFolder\NewImage.png:Zone Identifier

Clearly when you say *.png you mean to cover alternate data streams as well... I will fix this in the next beta I release. In the meantime try to add this setting,

OpenFilePath=*.png:*

Does that fix the problem on your end?

Having both settings works:
OpenFilePath=*.png:*
OpenFilePath=*.png

Thanks for checking.
I didn't think about alternate data streams.
In case of further replies, I'll be out of touch the rest of this week.

In version 3.49.09, file path exclusions such as

*something ( example: *.png )

also match

*something:* ( example: *.png:Zone Identifier )

Just a confirmation that this is resolved in 3.49.09