I believe new language wrappers would be best served by creating a vtkWrapC setup and then using the normal FFI mechanisms from that language from there. It’d get us quite a big bang-for-the-buck on the VTK maintenance side for new language wrappers for sure. But that would also be a big undertaking in and of itself anyways, so seeing consumers of such a thing would almost certainly be necessary before it actually gets made.
As for Rust specifically, I’m not sure how well VTK’s API communicates lifetimes of things, so that would also entail lots of documentation on various APIs for how to indicate lifetimes.
I agree wholeheartedly. If VTK had a well-defined and introspectable C ABI, then the bindings of many languages (including Python) could be made to be very lightweight. Instead of wrapping every single VTK class for Python, we could just have some generic translation code that handled all classes. Still a very big project, though.
Speaking of MATLAB, many years ago I worked on MATLAB-Simulink wrappers for VTK and ITK. It was a fun project, but there was very little interest from the community. Fortunately I was able to fold some of the effort back into the VTK Python wrappers.