First of all – fantastic work on the library! It's a clever approach and seems to be very well executed.
Regarding performance: It's really good to see that rendering performance is fast. However, my thought it still that any extra work that has to be done on every page request needs to be very carefully considered. I altered the benchmark script you provided to render 20 pre-parsed posts (the amount we load per page in Flarum), each the size of JoshyPHP's, and was getting results between 0.01-0.02 seconds (PHP 5.5, MacBook Air). That's negligible, but still, these things can add up. What do you think @Franz?
Regarding strategy: Flarum's current approach is to store raw, unformatted posts in the database, and then render + cache them when they need to be displayed. This way they only have to be rendered once, until the cache is cleared (if a formatting extension is enabled/disabled, for example), at which point they are rendered again, only once, on demand. I think the only downside to this approach is that it uses more storage space – but storage is dirt cheap these days, so that honestly doesn't concern me.
If we forget about storage space, what really is the benefit of TextFormatter's strategy over this one? If a formatting extension is enabled/disabled (say, BBCode is turned on/off), wouldn't that affect the structure of the XML – and thus, wouldn't you have to unparse and then reparse every post in order to update output?
One other minor concern is that it tightly couples all post content to a library. Storing posts as XML kind of obfuscates their content in the database, so if you want to go in and manually edit things, it's a lot harder. If people want to export their data, or migrate to another forum, it makes it harder.
Anyway, I really appreciate you reaching out to us. Definitely keen to consider it!