If you run your palette code in different targetengine the user shouldn't be blocked from main InDesign UI.

I'm afraid I can't help without seeing the scripts.

I had problems with the asynchronous resource downloads some time ago and

I decided not to use javascript for it. So my "Application.jsx" launched

external "Download.py" (Python) in the background, which started the download

without blocking InDesign at all.

The downside of it is that you may have hard time showing the download progress

to the user. If you want this you can have the external downloader write some

this-is-where-I-am kind of message to a temp file and have your palette

periodically look for its contents (with onIdle event) and display it as progress

message or construct some widget based on it. I never felt the need for it though,

as I have all my scripts write to a log so I can see it there. (less eye candy

but equally functional).

Harder part was to say goodbye to my pure javascript download code that

I crafted on top of the Socket object. But we have to accept that extendscript

is not omnipotent and when there is better tool for the job, I won't hesitate

to use it.

This may be a potshot in the dark, but how does it affect your issues with locked UI when you won't register your onIdle event?

How do you call `wget`? (`wget URL` vs `wget URL&`)

What happens when you execute "wget -b url -P pathToSave" from the command line? Do you have to watch the download process before you allowed to enter another command or  does it go to background, doing its job and letting to work? '-background' option seems to do the trick on unix version of wget

I'm surprised it doesn't do the same when run from InDesign