Do you have concrete plans to work on it? Otherwise I might be able to step in and build such functionality. It doesn't seem too hard to derive a AST-to-text serialiser from the grammar.

It is actually a very hard problem that requires complex analysis of the grammar. You're welcome to team up with the persons I mentioned in CC above, who already expressed interest in this topic before.

It was explained to me why it is a hard problem... but I forgot it tbh... we could add an issue for that problem that also contains the reasons why a generic approach is that hard. I can do it if s.o. gives me a summary.

From my naive thinking a serialization is just a model-to-text transformation... but it gets more difficult when you want to be stable from the previous state of the file... Docs... Ascii art... whitespace management...
Was that the core of the difficulty?

Some reasons why serialization can be a difficult problem:

1. As mentioned by @Lotes, how do we incorporate existing hidden-nodes (comments, etc) into a newly generated model?
2. For whitespace management, we would need a default formatter that can deal with most common grammars without mangling the output.
3. Some AST elements don't have clear rule association [1]. How do we determine which rules have to be used for serialization?
4. How do we serialize unassigned data? Keywords aren't an issue, but how do we deal with unassigned rules/fragments or terminals such as [2], where we don't know how to reconstruct it?
5. How do we efficiently deal with incorrectly constructed AST that the user wants to serialize?

[1]:

Add: Mult ({Binary.left=current} op='+' right=Mult)*;
Mult: Prim ({Binary.left=current} op='*' right=Prim)*;

[2]:

Rule: Term data=ID;
terminal Term: /x+/;