According to https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system
The FAT table contains last cluster for chain ("EOC") as values 0x?FFFFFF8 - 0x?FFFFFFF. It seems, KS only recognizes 0x?FFFFFFF, though as a test, I can see, that Linux dosfstools uses 0x?FFFFFF8 (this behaviour and compatibility problems even mentioned by the page). This can be an explanation why file systems created on some OSes doesn't work for us. The page also mentions about the fact, that FAT32 is actually FAT28, and the high 4 bits are not so much used to express cluster number but not always zero still, that's the reason of '?' marks in the hex numbers above (so they should be "masked out" before using a value as cluster?). It seems it's even recommended to treat any value in FAT which is over the max number of cluster on the given FS as "EOC", not only the range above, for better compatibility (as the page claims: "a good implementation ..."). This is exactly the problem I noticed with my M65 emulator with my own created FAT32: soon, invalid block is tried to be read on directory scanning, it can be the issue, that EOC (what is produced by my Linux box, but what is accepted by my various "stuffs" like digital camera etc) is misinterpreted by KS, and tried to be converted into SD block number the read -> thus the problem we see. As far as I know some other people also has problem like this.
I think, "sensing" EOC should be modified to care about these information too, including the 4 high bits issue, the multiple possibilities for EOC, and maybe even that any cluster number in FAT should be treated as EOC, if it would cause to address a cluster which does not exist on the used FS. This should be true for directory parsing, but also, for any file, where FAT is used for anything to detect EOC situation. Also maybe not only EOC, but cluster info from FAT should be handled to use only the lower 28 bits just in case for some "strange" FAT32 file systems, and even better compatibility.
I found this table especially useful (it mentions even more EOC possibilities, like cluster 0 and 1 ...):
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Cluster_values
The other issue is more like a performance gain than a real issue: again, according to the page above, during a directory read, if the 32 bytes directory entry starts with byte 0, directory parsing can be stopped. So even there is no need to parse the rest of the cluster (or read the next logical sector belonging to the actual cluster ...), and maybe no need to even check for next cluster then in FAT. It seems, this can be a compatibility issue in general in case of older FATs (FAT12 and FAT16) with some extreme old DOS versions, like DOS 1 and DOS 2 and some half-CP/M-half-DOS beings. However, as FAT32 is surely not handled/produced by these, I think, we can surely say, this theory is true for our case with FAT32-only KS. Even deleted files has first byte as 0xE5, zero should only encountered if no other entries follows in the directory (let it be the root directory or any other - as with FAT32 there is no difference, unlike with FAT12/16). Reference:
https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#Directory_entry