I can't brain right now, so I'll have to think about it and come back to you.

Realistically, I don't think anybody would want to implement a completely new text_formatter service. I've created interfaces and abstract classes to preserve that possibility, but by the time I was done I felt like it was a mistake. Even though it's tempting to engineer the kind of solution you're describing, I think it shouldn't be done unless there's a clear need for it.

Wrt additional/custom parsers, many use cases can be addressed with s9e\TextFormatter's Generic plugin (which supports HTML-safe regexp replacements) and those that can't may be more efficiently implemented as a custom plugin for s9e\TextFormatter.