I create a new node for rendering because VR3 understands how to render markdown with the @language directives but the @jupytext tree isn't markdown. If the leading comment signs were removed and the code sections fenced then VR3 would be able to render the entire tree, but not the way things stand now. I don't want to change the actual @jupytext tree because then it wouldn't save correctly with the current save code.
The importer could have created the file tree such that VR3 could render it directly, but things went in another direction.
When I incorporate the conversion code into VR3, there won't be a need for this script - or for creating a new node - but until I do that, this script allows you to view the rendered file. Getting the script out there to be used can also help me make sure the conversion is solid when I do build it into VR3.
In addition, I think a possible use case is that after selecting a jupytext child node, only the content of the current child node is rendered, and the rendering is performed while changing. It may be more convenient for latex-related things.
I can do that when I get the code into VR3 itself. Thanks for the suggestion. I'm not sure how it relates to latex, though. VR3 doesn't know how to render latex code per se. If it's in a fenced code or literal block, it will be rendered as source code. If it's MathJax, it will render as equations - they look really good. VR3 is probably never going to render latex code except as literal source code, because the whole process is too complex and would be much too slow to be practical. Sure would be nice, though!
I have not started to modify VR3 to render @jupytext files directly because I wanted to have some confidence that the format will be stable.