i think you’re looking for a 100% future-proof guarantee from the iNat staff that they can’t provide.
they are not writing their own code to interpret markdown. they are using code that others have written to interpret the markdown syntax. so it’s those other people who are deciding exactly how the markdown will be parsed / interpreted / processed / rendered / etc… (that other code is what i’m calling the parser, interpreter, etc.)
what makes the situation worse is that there is not a single standard in markdown to handle tables, as far as i can tell. for example, these are two different specifications for handling tables:
- GFM (Github Flavored Markdown): https://docs.github.com/en/github/writing-on-github/organizing-information-with-tables
- PHP Markdown: https://michelf.ca/projects/php-markdown/extra/
… and different folks can write their parsers to handle to whichever specifications they like.
so if, at some point, iNat folks decide to use different parsers to handle the markdown, the new parsers may handle the markdown slightly differently than the original ones. or if markdown standards evolve, and the parsers change to handle the new standards, that may mean that old markdown syntax may no longer be supported in the updated parsers.
note that i’m using parsers (plural) above – because i think iNat uses different parsers in different places. you can already see how fragmented the situation is in iNat. take a look at this syntax for tables (which is just fine according to PHP Markdown but is not proper syntax according to GFM):
the forum interprets it just fine, a journal post in the main site interprets it just fine, but the observation detail page will not translate into a table. i think that’s because the journal page uses one parser and the observation page uses a different parser (because they are written using two different code architectures, i think).
complicating things further, if you add a markdown table to an observation (either in the description or in a comment), and then you look at it in the Android app, the app doesn’t show you a table at all (because the app code uses yet another parser, which i suppose doesn’t handle tables at all). if you pull it up in a browser on the phone, though, it looks fine (because the web on a computer is more or less the same as the web on the phone).
that said, i would suspect that as markdown standards evolve, the GFM syntax:
… will probably end up being the most well-supported (a de facto standard), if it doesn’t end up being the standard altogether (just because it’s so commonly used). so if you want the most future-proof markdown syntax, i think that’s it right there. (but, again, i doubt that anyone will guarantee that syntax to be 100% future-proof.)
however, i would suspect that most parsers of the future – and even now – will also support: