This is very likely due to the change to the new Apple file API under the hood in 2019 but I hope that its a bug that Xojo can fix and not just the way things must work now. My feedback report with a demo program is here: <https://xojo.com/issue/58207>
What this means is that if you, or anyone else changes the name of a parent folder anywhere in the path of the new folderitem between the time you created the reference and when you try to actually work with the file that will break it.
I found this while testing my app this morning. When saving a file I create a folder inside its bundle with a default name. Then create the folderitem reference to the files inside of that folder. When the user saves the document I rename the default name of the folder to their name and then try to create the contents. But there are any number of other ways this could bite you. If you create a folderitem and do not immediately create it and the user changes any foldername in the path then when you go to use it youll get an IO exception instead because the path becomes invalid.
With any version prior to 2019r2 this worked fine, the new folderitem reference was aware that it was a child of a parent folder and not just a text path, if you or anyone changed the name of anything up the path the new folderitem would still display the correct path. This no longer works.
The work around is to just re-create your folderitem if you have to change the name of anything upstream in the path. This is possible if you know this is now how it works and youre the one doing the renaming. It doesnt work at all if the user renames something while youre holding the folderitem reference.
Once the file is created then it appears to work as before, this only affects folderitems that you have a reference to that dont exist yet.