Overhauled macOS support; Save/load animation editor color palettes; Loads more.
I'm afraid file system operations must be asynchronous to support both browsers and wrapper extensions.
For what it's worth, pretty much all modern storage APIs are asynchronous, so it is normal that doing something like file system access is asynchronous. Synchronous operations for that kind of thing have poor performance and can heavily jank the game, or in some cases cause it to freeze for periods of time.
I understand the async bit. I'm actually curious why NW.js wasn't async.
But regardless, I still think the workflow can be easier! Is there any chance, for example, that listing contents doesn't have to be necessary for pre-given picker tags, like "<documents>"? Why can't I get the name of a file, or it's location, after a "File operation complete" trigger? Is using tokenat() on a file tag the only way to send data with a read file request?
NW.js provides both sync and async file system operations. Basically it was a mistake that when making the NW.js plugin we used sync file system operations. We should have chosen async.
I'm not sure what you're trying to achieve with the other details about the File System plugin. I imagined most games would do something like write a handful of files for save data and that would be it. If you have complex use cases involving listing lots of files and passing data along with file system operations, what is it you're trying to achieve? It might be better to move to the forum to discuss this.
construct.net/en/forum/construct-3/general-discussion-7/filesystem-workflow-quite-184377
Thanks for listening :P