Thank you for your insight @will.schroeder. I fully agree with you. Probably I’m just worried that users will be mislead by seeing the new file format specification on an official VTK site and will think that this is some new VTK feature.
Implementing this new scene file format and corresponding parser and viewer in a separate repository (not in an official VTK repository) would avoid the confusion and it would also have the advantage that it could be more conveniently available for users. Users would not need to download or copy-paste code from VTK examples site and then build but there could be precompiled binary distributions and could be also made available on PyPI. Also, there would be more space to grow in a separate repository, it would be easier to gather a small community around this tool.
This could be yet another example of a VTK remote module, because it would not be a VTK core feature (no commitment from VTK core developers for design, implementation, maintenance, and support), but it could become much more than just a rendering example.