The problem with your current workaround is that, while it does make editing the actual text fine, changing any of the text properties still causes a lockup. I'm actually finding that leaving the main STM editor visible while typing into the STM Text Send hardly makes any difference.
Something to try would be to cache and remove all text in the main text box before modifying any properties and then restore the text afterwards. In fact, if this happens quickly enough, it could be seamless enough that the user wouldn't even notice.
As for my use case, I just want to be able to type rich text and be able to immediately see how it will look in-game for:
- Tutorials and in-game wiki pages: this is where the really long texts are
- Tooltips and card descriptions: these can be a up to a paragraph or two.
It's somewhat usable for tooltips and cards (though far from a great user experience); and pretty much unusable for tutorials and wikis.
Franky speaking, the reason I bought STM was because I determined it would take too long for me to fix the bugs in my own rich text system; but if I have to deal with super slow performance and/or incomplete workarounds I'd rather just take the time to get my own system working properly.
So I guess it depends on how much time you're willing to spend fixing this (I'm quite surprised I'm the first person to report it, by the way - I would think you'll get a lot more users running into this as people upgrade to Unity 6). If you think it's a niche use case and not what the asset was designed for and you don't want to take the time to fix it, I understand - I'll just refund it and look for other options. If you are willing to fix it, though that would be great, because it does seem like a really complete text solution; but the fix will need to be more comprehensive than the workarounds you've provided thus far.