The expression returns the correct path - e.g. "/home/username/Desktop/". This is a valid path for the file system. The problem is if you make a request to this treating it as a URL - such as you do to issue an AJAX request and load an image - then it's routed through the browser URL resolution. This is not the same as a file path. It expects URLs of the form "https://www.scirra.com", but you pass it something like "/home/username/Desktop/test.txt". This looks like a relative URL (e.g. fetching "/folder/file.txt") so the request happens to be made relative to the current URL, which happens to be something based on chrome-extension:// for NW.js apps. The problem probably only does not happen on Windows because the different file path style with a drive letter unambiguously identifies a local path. You can force it to treat a path as a local URL by prefixing "file://". So your example actually starts working if you add "file://" before the request URLs. That's a nice easy workaround for the time being!
So far everything is actually working correctly. The real problem is confusion between file paths and URLs. We can't change AppFolder because adding "file://" is incorrect for actions that directly manipulate local files. But then you can't directly use AppFolder in a URL expression without prefixing "file://".
So I think the best solution is a new expression AppFolderURL, which has the "file://" part automatically included. Then you can use AppFolder for local file stuff, and AppFolderURL for anything treated as a URL. This will be added in the next build, but you don't need to wait, just add "file://" for now and it works.