Thanks for your response. I had the thought later that it could be a caching thing, since part of the recent change required flushing the existing cache of content for this remote links file. So, given there is a request time limit and you have a rather extensive list of private content, it could be struggling to repopulate that cache to keep the request fast enough to stay under the limit. If this is the case, then every attempt to download should make more progress than the last and we should get to all of it with enough retries.
Before this change the cache would have been hot enough that new content you make is easy enough to add to the list, but after the change, it has to generate all of it at once. Does this make sense and fit with your experience? I just checked and fetching your file now matches the file I generated for your user several hours ago, so hopefully if this is the issue then it has self resolved.
As far as I know, FGU is making the same request as the download on the website, but it most likely discards a lot of the columns that we provide with our download option. Part of the motivation of the problematic change was to allow third parties like FGU to choose the fields they want in the response when they request the file, which could significantly reduce the overall filesize for them, but I imagine they have not implemented this yet.
Hopefully the few improvements made to the endpoint can eventually justify these early teething issues, and we can get over this hump together! 
P.S: I sent you a direct message that you may not have seen, you can respond there also if there is anything in that message that needs clarification, and it may help troubleshoot to be able to more freely go into detail about your content and what is and is not working specifically (detail you may not want posted here 
).
