I try to be mindful of making my software as accessible as possible, but the following
> creating a lookup table for all the unicode material out there might've been considered impractical or performance-hitting for the developers.
just doesn't ring true to me in any way for current software. I understand that people can be using older software, which is why I strive to restrict myself to ASCII as much as possible for the widest possible support for my users, but my software also supports unicode identifiers, up to and including a whole unicode table to talk about confusables[1]. And not all TTS software "ignores" characters, which is why people advice against using 𝑓𝑎𝑛𝑐𝑦 unicode because it doesn't get read as text but instead each character is described individually. (This is also something that TTS software should support for their users' sake, but I digress.)
To be clear, it is reasonable to be practical and cater to the software as it exists, but that doesn't mean that we shouldn't ask for better software.
I think that you touched one of the reasons why not all unicode characters are supported. You said that it is not recommended to use identifiers with confusables because they will be wasting the time of the SR user. Imagine though that someone decides to write an entire text in english using lets say the french or german alphabet, putting accented or umlauded letters everywhere where it is possible. Now, one can say "lets convert the confusable to the main form and read it like that", but what happens if you stumble upon a new text where there is a meaningful difference between the accented and not accented letters? The situation is not hypothetical, because very often one can find either a multilanguage document or a book with with names and single words in another language.
> creating a lookup table for all the unicode material out there might've been considered impractical or performance-hitting for the developers.
just doesn't ring true to me in any way for current software. I understand that people can be using older software, which is why I strive to restrict myself to ASCII as much as possible for the widest possible support for my users, but my software also supports unicode identifiers, up to and including a whole unicode table to talk about confusables[1]. And not all TTS software "ignores" characters, which is why people advice against using 𝑓𝑎𝑛𝑐𝑦 unicode because it doesn't get read as text but instead each character is described individually. (This is also something that TTS software should support for their users' sake, but I digress.)
To be clear, it is reasonable to be practical and cater to the software as it exists, but that doesn't mean that we shouldn't ask for better software.
[1]: this is thanks to the crate unic-udc containing this information: https://github.com/open-i18n/rust-unic