Yes, that would be a huge problem. I completely forgot about the whole resource-fork thing.
To build a standalone on Mac OS 9 and lower, you'd need to create a specific OpenXT MacOS 9 version. That would be a huge amount of effort for the limited numbers of users who actually still depend on it (specialist manufacturing, some science labs, legacy audio production workflows... that kind of thing).
You are spot on. When I was a kid, I remember trying to download everything from various freeware and shareware sites from an internet cafe (I used to volunteer to help there, and would utilise what I considered their amazing-at-the-time 1MB/Sec connection).
If the files were not stuffit compressed, or HQX encoded, the resource fork would have been instantly wrecked the moment it crossed into a filesystem that didn't understand data forks and how to handle mac resource files.
So I remember downloading a load of stuff the first time, then learning the hard way that it was all garbage when I opened it on my mac back home.
Seems to still be the case with Linux, and even with an HFS+ fuse filesystem, It can't seem to handle resource forks properly.
(or perhaps it's not aware of the "macintosh standard HFS" format - before HFS+).
Simpletext is a Mac Application, and when you view the same directory in Linux, it's a 0 byte file. All the data for SimpleText is in it's Resource Fork. There's no data fork for this on the mac. (Macs could support storing resources in the data fork, but this wasn't made a rule, so most continued to use Resource forks.)
Interestingly (or not, depends on how much people care) - SuperCard 4, back in the day, used to have an option for moving things in the resource fork over to the data fork, so that mac standalones would survive copying through a non mac-forked-filesystem:
Afterwards, If you tried to open the project with something like resedit, it wasn't aware of storing resources inside the datafork DF:
But, if you opened it with something that was aware of this idea (such as resorcerer), then you could see the file and it's contents would survive the trip across a non-mac-filesystem:
So, here's where a suggestion comes in.
If it were possible to recreate the mac compiling engine to do it's work in a linux version of OpenXTalk, then in theory when building the mac standalone, it just has to understand to package everything it needs into the df Datafork of the Mac standalone.
It wouldn't then matter about resource fork compatibility as there is no resource fork. In theory, the mac application would survive a trip across a non-mac filesystem, but would lose file type and creator settings ("APPL" and "???" in this case), and you'd lose any custom icons applied to the application as the icls,icl8, and more would be obliterated - as MacOS 9 and lower always looks for these in the Resource Fork, not the Data Fork when updating it's icon information.
Sorry if that's incredibly boring for anyone, but it does illustrate the challenges of system-interoperability.