step 2, findings for iOS:
after review I still think my table is fundamentally correct, the bugs are for real. A few more details follow. All files on iOS are either located through the 'files' application, or photos. This of course has it's own built-in limitations. Nevertheless,
one should be able to add / view / retrieve or remove a pic, a txt, or a binary file.
On entry B12 (see original table), binaries cannot be selected from within Joplin to be attached (greyed out). So there is no need to think about other operations.
Pictures work fine when it comes to add / view and retrieve. What isn't ideal, there is no feedback after selecting "save image". You don't know it worked until you open your camera roll, and the file name is lost in the process. Another (minor) problem with pictures. If you edit an entry's link string by accident it cannot be restored and it is unclear what happened to the picture. (note: unlike the situation on the desktop).
Text files (entry D10 of the table), one can add and view text files. Like on desktop, it would be nice(r) if one could see the text or at least the first few lines. Anyway, when you choose 'share' from the iOS text viewer, and select 'save to files' ... the file name is lost in the process and replaced by a long string (prob. the ID# of the attachment + ... and the extension txt). No problem if you have few files, just one file to retrieve and all in just one location. But hopeless in many other cases.
The fact that you can remove the link to an attachment, but not the attachment itself has me wondering a) whether this way your db might grow bigger and bigger (if sync does not remove the attachments later ?), and b) whether a sensitive file stays forever in your (iOS) database and there was nothing you could do about this.