If I understand the suggestion in the linked post, this sounds like too big a departure from the current Content Translation architecture, so it cannot really be part of this project.

The more general original issue of providing Content Translation to other projects like Wikivoyage or Wikiversity is legitimate, but not something that we plan to work on immediately. Even though it sounds simple to install it on more wikis, actually supporting such a deployment is not trivial at all. We do plan to do this in the future, but only after stabilizing the current iteration of Content Translation.

Can you clarify how feasible Bert's proposal is? In general, not necessarily for the purposes they had in mind.
What I'm trying to figure is whether this is a kind of project that may not fit your team now/ever, but could be good for volunteer devs and similar.
TY!

We don't want a separate version of CX that would compete and differ from CX. The only webapp specific feature I can think of is full support for doing work while offline. But offlines requirements are in conflict with how CX works. Anything else should be possible to improve in CX itself.

Offline work would IMHO best served by some kind of import/export API, ideally using a format shared with Translate (XLIFF2? :p), so that people can use existing software for translation. https://www.mediawiki.org/wiki/Help:Extension:Translate/Off-line_translation

Then I can imagine a future where the format evolves to better support complex strings and translation software converges to offer both wikitext/HTML5 features and typical translation features (translation memory etc.) and to be shared by other projects which have such offline editing aspirations, such as Kiwix.